Anyone with a answer to this ? ----- Original Message ----- From: "Max Rydahl Andersen" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Sunday, September 08, 2002 6:45 PM Subject: Re: Anyone up for a "challange" ? :)
> > <snip>> > > > I just wonder how the testcases can be succesfull in the J2EE > junit-tests. > > > Shouldn't they fail reliably if clients try to modify the same data ? > > > > > > > we have no J2EE tests yet, as this would require to setup a complete > > container for our testsuite. > > Well, the mulithreaded testcases should also fail (and I think saw somekind > of threaded tests in the testcode, or ?) > > > <snip> > > >>that is of course also possible. Just set the attribute > > >>auto-retrieve="false". > > > > > > > > > Well - that I know, but then they will be retreived when I try to access > > > them - And that I do not want on the client...se more below. > > > > > > > No!, they will just be set to null! no dynamic lazy loading if > > auto-retrieve="false"! > > Ok - I thought auto-retrieve "enabled" the proxy mechanism. > > > > > > >>>And using proxies is also not an option as I want to send the "object > > >> > > > graph" > > > > > >>>to a "remote"-site (e.g. client) where > > >>>there is no knowledge of a PersistenceBroker. > > >>> > > >> > > >>The OJB proxies are remote capable! You just have to run OJB in c/s mode > > >>to enable safely serializable proxies! > > > > > > > > > Yes - I know. But for security and performance reasons we would not like > the > > > client to be able to retreive these objects remotly. > > > Arguments: > > > > > > 1. The client should only get data through our session beans which can > check > > > for permissions on the data. > > > 2. Relationships is required to be stated in the repository.xml before > they > > > can be accessed as e.g. X.myY.fromData. > > > Thus by requirement clients can without asking for "permission" > access > > > and accidently load all of the database - not good! > > > > > > > OK! should be possible with auto-retrieve="false". > > (It is also possible to change the auto-retrieve attribute at runtime, > > to modify the loading behaviour if needed.) > > But this is (as we discussed in another thread) not a threadsafe operation > as the repository-keeper is > shared amongst PersistenceBrokers. > > > > If just I could have a method like OJBHelper.fillInRelation(X, "myY", > new > > > SomeCriteria()) which would insert or just return a collection for X's > myY > > > field - but only those Y's that fullfills the SomeCriteria(). > > > > > > This would make it possible for my sessionmethods to gradually (under > > > control) fill in the object graph. > > > And if the client tries to access the relationships before they have > been > > > filled in (under control) then I would throw an exception. > > > > > > Am I still making my self clear ? :) > > > > crystal clear! This relationship helper is something I have thought > > about in the last week. As all needed functionality is already > > implemented in the PersistenceBroker it will be pretty easy to expose > > such a feature in the public API. > > I will put this feature on my personal todo list. > > I just hope the todo list is not too long :) > > /max > > > > > > > > > > > > >>>>>Even better/more flexible could be to be able to state: SELECT X.*, > Y.* > > >>>> > > >>>from > > >>> > > >>> > > >>>>>X,Y where x.date > y.fromdate and x.date < y.todate > > >>>>>And then have OBJ return a list of pairs of objects of X and Y class. > > >>>>> > > >>>> > > >>>>This is not possible. > > >>> > > >>> > > >>>No, but it sure would be nice - would'n'it ? > > >>> > > >> > > >>Would be nice, but: > > >>It would safe only one additional broker call. > > > > > > > > > If there are 100 X's and e.g. on average 5 Y's matching an X - then the > > > above query would save 99 queris to the database! > > > > > > > > >>On the other hand it would require a complete redesign of the current > > >>Query implementation. > > > > > > > > > Nah, would it ? Is there so strong a binding on the Query implementation > on > > > only returing one "column" of objects ? > > > > Yes the whole thing is meant to materialize objects of a single type > > (with some improvements for polymorphism). > > > > > > > > > > >>I have never missed this feature in real world projects. There have also > > >>been no user request asking for this feature. > > > > > > > > > It could save some queries to the database - so for performance reasons > it > > > would be nice. > > > > > > The alternative is to use ReportQueries as you stated - and then > manually > > > load the X's and the Y's. But then all the "good" properties of the > objects > > > such as uniqueness, optimistic locking and etc. would not automagically > be > > > fullfilled - would it ? > > > > correct! > > > > > (Here i am concerned about what if the programmer > > > doing this forgot to fill in some part of X and Y by accident ? This > would > > > not happen if OJB had the general methods for doing this (except if > OJB's > > > developers forgot that little thing :) > > > > > > > Did you have a look at our RowReader concept (see tutorial3.html) with a > > RowReader it won't be too difficult to have X and Y objects > > materialized from the same ResultSet. > > > > cheers, > > Thomas > > > > > > -- > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
