Hi again, <snip> >> >> 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. >
Yesterday I implemented PB.deleteByQuery(Query) and commited it to CVS. So if you are eager to experiment with this feature you can already use it! cheers, Thomas > 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]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
