Tim Drury wrote:
>I was under the impression that the container implemented remove()
>for you to simply delete the DO from the database. When you call
>"depobj.remove()" from the DO's parent, it gets deleted.
>I could be wrong - it wouldn't be the first time.
That's true!
However Orion does not yet seem to support remove on dependent objects.
It doesn't support ejbCreate either. The container never calls this method
and if you have arguments (i.e. ejbCreate(String pleaseWork) it would
result in an error from Orion.
Relations between dependents are not supported. Orion returns an error on
the abstract create method.
You can have relation between DO and Entity (i.e. do -> entity), but Orion
creates the tables wrong and therefore it also seems that this is not yet
supported.
Dependent objects cannot have primary keys. But as Jeff, with a reference
to another guy, pointed out this seems to be a typo in the spec. I totally
agree.
I also checked referential integrity and data aliasing in the persistence
manager and here the guys behind Orion have lot to do. Or, maybe it is up
to the programmer to uphold the cardinality and check for duplicates (what
do you think?). Anyway I did some tests:
If you have to entities that have a reference to the same DO and you change
the DO by one entity, the reference that the second entity holds on to is
not updated (data aliasing).
You could also easily break the referential integrity (in the persistence
manager). I you have a unidirectional one to many relationship between
entities, it is possible to let entities on the many side to refer to the
same entity in the one side.
I could be wrong in these statements. If I am, please correct me.
Regards,
/Theis.
