> <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]>
