Hi again, <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. <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"! > >>>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.) > 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. > > >>>>>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]>
