Hi again, > 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 ?) > >
but non of them fails... :-) > > > <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. Now it's possible to have one descriptor repository instance per broker. SO no more threadings problems for such operations... > > > > > > 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 :) already implemented and checked into CVS... cheers, Thomas > > /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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
