I definitely agree with all your points. As a matter of fact while there
were still entity names for identifiers I often wondered why Cayenne had not
relied on entity classes from the beginning. But from the general standpoint
data maps had been self-sufficient before the change. I mean, Cayenne had
been able to generate and handle new types of DataObjects at runtime without
any kind of actual compilation. It is good to have such a thing sometimes,
isn't it? Presently one has to compile at least formally customized Java
classes. Of course those completely dynamic types are a rare case as well as
any usage of Proxy is (for example one could wish to use the existing object
types for data objects and use Proxy to implicitly implement the DataObject
interface). All that said, the new approach is purer and works better in
most cases, so I am ok with the price.
Andriy.
>
> Welcome aboard Andriy! :-)
>
> Andriy Shapochka wrote:
> > It is probably too late to say this, but in my opinion introducing
> > DataObject classes as new ObjEntity identifiers instead of ObjEntity
> > names in EntityResolver negatively affected Cayenne flexibility and
> > usability. Before this replacement it had been possible to create
>
> I'm afraid this is something that I came up with, and while I agree on the
> impact on flexibility (no constraint by using a simple string is obviously
> more flexible than a class coupling) I disagree on the usability part -
> simply speaking from experience. In real life and when you have
> not-so-smart people on a team, at least giving them a skeleton to hold
> onto is very helpful. Too often have I seen mappings where the object
> model entities had exactly the same names as the DB tables and were
> basically a 1:1 exposure of the physical structure - 'just because it's
> easier to remember!'. How terrible! At least encouraging the use of 'real
> classes' - often done not by the DBA but rather someone who models
> business logic - allows many people to 'safely' forget (at least in many
> places) the table names.
>
> I understand why this was inconvenient for your (very cool, btw!)
> regression test, but then again randomly creating schemas and entities is
> not exactly a typical use case.. the average DBA/project mgr would
> probably get a heart attack. :)
>
> > and such. Also, any possibility of decent usage of dynamic proxies for
> > DataObject implementations is eliminated now.
>
> OK, that is definitely correct but I cannot think of a 'real world'
> scenario where that might be required - can you explain a little more?
> Unless the proxies present remote objects (which opens up a whole
> different can of worms, just like entity beans) I cannot see that this
> would buy me anything that a class-based coupling really prevents. A
> 'proxy' class acting on behalf of another class might then have a (maybe
> dynamically created) 'proxy' ObjEntity mapping to the 'real' entity in the
> data store.
>
> Maybe it is reassuring to know that JDO has the same problem, since you
> specify queries on an 'Extent' with a class as the argument. Typesafe &
> easy to use, but in the end the same dilemma.
>
> Holger
>
This archive was generated by hypermail 2.0.0 : Sun Feb 02 2003 - 17:18:27 EST