>
> How many existing object relational mapping tools allow a developer to
> incrementally deploy and evolve a complex object schema while providing
> fully managed relationships that support full navigation and referencial
> integrity?
not many, agreed. we have implemented roughly the functionality of CMP 2.0
(navigability, relationship management) on top of CMP 1.1 in a code
generation tool and it works fine. so I don't see the issues with allowing
remote relationships (that's basically all I'm asking for). it might make
referential integrity enforcement and TX management a bit trickier for the
CMP implementor but doesn't affect the O/R mapping part.
>
> This was a problem that OODBs had great difficulty solving (some would
> argue that it was never fully solved). OR tools have never, to my
> knowledge, solved it. They always require that an object schema be
> evolved as a whole and deployed as a whole.
I don't have a problem with redeploying the entire abstract schema if I make
model changes. however, if a change in implementation code of an entity bean
requires me to redeploy the entire model it's a bad hit on development cycle
efficiency (at least with appservers I know). currently I only redeploy the
affected (rather small) ejb-jar representing the subset and everything is OK
despite of relationships with other subsets.
>
> If CMP were to have required that EJB containers provide unbounded
> incremental deployment of a single object schema what technology would
not unbounded, see above
> they have used to meet this requirement? How much would you be willing
> to pay for such a groundbreaking solution? How long would you be willing
> to wait for it?
>
> EJB CMP is simply a standard API for a container provided object
> relational mapping tool. It benefits from the fact that the container
> can optimize its integration with the EJB lifecycle; however, CMPs
> design was specifically restricted to allow it to be implemented with
> existing OR technologies.
ok, but to be specific, is this the reason why remote relationships were
dropped?
>
> As others on this thread have noted, large apps need to be architected
> as loosely coupled modules. By definition, these modules can't be
> implemented with a single intertwined object schema.
I have already agreed in this thread that this is a valid best practice
approach but still I find the restrictions on crossing subset boundaries the
current spec imposes rather awkward especially if ejb-jars are used for
partitioning the app for maintainability reasons rather than to have
completely independent reusable components, which is a valid approach if you
ask me. are there any plans to include remote CMP relationships in the
future?
best regards,
robert
>
> -- Mark
>
>
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
