On Wed, 2002-09-18 at 16:30, Thomas Mahler wrote:
> Hi Scott,
>
> Scott C. Gray wrote:
> > I think I know what is going on here, but I want to find out if
> > this is the "correct" behavior of OJB (I'm using the PB layer
> > of 0.9.5, BTW).
> >
> > I have a collection descriptor that I am using for the soul
> > purpose of managing cascading deletes:
> >
> > <class-descriptor
> > class="com.inventa.schema.node.impl.NodeImpl"
> > table="NODE">
> >
> > ...
> >
> > <collection-descriptor
> > name="noteList"
> > element-class-ref="com.inventa.schema.node.impl.NodeNoteImpl"
> > auto-retrieve="false"
> > auto-update="false"
> > auto-delete="true">
> >
> > <inverse-foreignkey field-id-ref="2"/>
> > </collection-descriptor>
> > </class-descriptor>
> >
> > That is, I have a Vector in my NodeImpl class called "noteList"
> > that will _never_ have anything in it (because I have auto-retrieve
> > set to false and I never use it myself), but I have it defined
> > because I want the PB to cascade deletes to the NodeNoteImpl object
> > when I delete my NodeImpl object.
> >
> > The behavior I am getting, however, is that the PB does _not_
> > attempt to delete any NodeNoteImpl's when I delete a NodeImpl.
> > My guess is it is because my noteList Vector is empty.
>
> exactly!
>
> >
> > Is the correct behavior?
> >
>
> works as designed. if the collection to be deleted is empty no elements
> get deleted.
But, the only way OJB would know if there are any elements
is explicitly if 'auto-retrieve' was set to true which, for
my purposes anyway, is not what I need.
In my example above, I am use the <collection-descriptor>
only as "documentation" of the relationship between objects...
in some cases the 1:N relationship could be 1:1000 or worse,
so I don't want OJB retrieving all 1000 sub-records in
order that it should know it needs to delete them. Ideally,
you could have a new value for auto-delete called "always"
<collection-descriptor ...
auto-retrieve="false"
auto-update="false"
auto-delete="always">
Forcing a cascading delete on all children in the collection,
whether or not OJB has retrieved them in the past (yes, you
will be issuing a potentially useless delete, but I have
explicitly given you the go-ahead with the "always" flag).
However, I did take the time to read through the OJB sources
(I am a firm believer in RTFS--"S" = Source) and after looking
through how OJB caches object state information I realize that
it would be very difficult to track down which items needed to
be removed from the cache due to the blanket delete--it is doable,
but would take some effort.
For now I have had to resort to manually cascading deletes.
> > BTW, (feature request), it would be nice to have a special
> > descriptor for just what I am trying to do--simply define
> > a relationship without having to refer to a member field
> > of an object to "store" that relationship.
> >
>
> WHat do you want to do with this special descriptor? I don't get your
> idea yet.
My suggestion is this: If I am using a <collection-descriptor>
as in the example above, only to define a relationship between
objects and maybe give some hints as to how to cascade deletes
(if there was a way to implement what I am talking about above),
why does the "name" attribute of the collection-descriptor
need to actually refer to a real member field a class? That is,
you could have:
<collection-descriptor
name="userAddresses"
element-class-ref="com.somecompany.Address"
type="virtual"
auto-delete="always">
...
</collection-desriptor>
This would allow you to do joins using Criteria objects
and (hopefully someday) do cascading deletes without
actually have an unused member field called "userAddresses".
Thanks for your feedback.
-scott
--
Scott C. Gray <[EMAIL PROTECTED]> | Quidquid latine dictum sit, altum
Director of Engineering, MWS | videtur -- Whatever is said in
(V) 856-914-5212 | Latin sounds profound.
(F) 856-608-7970 | -Unknown
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
