Hi Scott, Scott C. Gray wrote: <snip> >> > > 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.
correct! You have to take in account that the persistence broker is a low-level persistence engine meant to build higher level functionality on top of it. > > 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). Now I get your idea. I propose the following: To get started with such a mechanism we first need a way to delete by query. We can add a method deleteByQuery(Query) to the PB Interface. This will allow to delete the N-side objects without materializing them. This feature will be useful for everyone, easy to implement and work as first workaround for your problem. Then we will have to discuss if it is a good idea to implement your "always" concept. IMHO such a cascading delete should be issued from client code and not implicitely by the broker. > > 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. That's the main reason why the deleteByQuery(...) has not been implemented yet... what do you think? cheers, Thomas > > 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 > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
