I forgot a couple of "arguments"..... 3. When the objects (proxies) are serialized onto the client then the proxy has an internally reference to the persistence broker that "gave birth" to them - and this persistence broker is probably holding a reference to a connection to the database - That is NOT healthy in a 2/3-tier solution. Or have I misunderstood how it works ?
4. And in C/S mode the "client" also have a persistencebroker, right ? Then the client suddenly can access the database without having the app.server as a middle-man ? /max > > 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! > > 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 ? :) > > > >>>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 ? > > > 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 ? (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 :) > > > /max > > > -- > 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]>
