[OJB-developers] Cache of Collections

[John W. <hw...@re...>]

I am wondering about how JOB handles the cache of collections?
Say, A has many B,
first I get A, it contains a collection of B, and the object A is put into
the cache
then Another user has added an object B, this time the object A's B
collection should contain the new B,
Can JOB handles that? Or at least it should invalidate the object A or A's B
collection.

BTW, does client/server model work for the current version? (0.7.343). And
it support distrubuted cache of objects?

Thanks a lot,
John W
----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Georg Schneider" <ge...@me...>
Cc: <obj...@li...>
Sent: Friday, March 08, 2002 10:59 AM
Subject: Re: [OJB-developers] OQL bug


> Hi Georg,
>
> Oops this is a very tough problem. This will be quite difficult to fix.
> The best thing would be to support usage of methods in OQL query like
> "select x from X where getSequence().getSomeField() = $1"
>
> This way we could avoid all the trouble caused by looking for persistent
> attributes in interface classdescriptors.
>
> I'll put this on the todo list. But it will take some time to fix! (Any
> volunteers?)
>
> thanks,
>
> Thomas
>
> Georg Schneider wrote:
>
> > Hi,
> >
> > when something similar as the following OQL-Query
> >
> > select allX from X where sequence.somefield = $1 ....
> >
> > where the sequence field is actually an interface I get a
> > NullPointerException:
> >
> > java.lang.NullPointerException
> >         at
> >
ojb.broker.metadata.ClassDescriptor.getPkFields(ClassDescriptor.java:869)
> >         at
> >
ojb.broker.accesslayer.SqlGenerator$JoinInfo.asSqlClause(SqlGenerator.java:6
6)
> >         at
> > ojb.broker.accesslayer.SqlGenerator.getJoinClause(SqlGenerator.java:914)
> >         at
> >
ojb.broker.accesslayer.SqlGenerator.getPreparedSelectStatement(SqlGenerator.
java:685)
> >         at
> > ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:186)
> >         at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:179)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBr
okerImpl.java:1181)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:901)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:986)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:958)
> >         at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:229)
> >
> >
> > I looked a little bit around and the problem seems to be in the inner
> > class JoinInfo in SqlGenerator which tries to do the following
> >
> >             refCld =
> > aCld.getRepository().getDescriptorFor(anOrd.getItemClass());
> >
> >
> > anOrd.getItemClass() of course is an interface which as a Descriptor
> > doesn't have any fields. I suppose the interface would have to be
> > substituted somehow by the actual classes implementing that interface
and
> > maybe this would mean having to do various actual SQL-Queries each with
a
> > concrete class and then somehow merging the result, or doing an
> > (outer) join over all the concrete class tables involved and then
somehow
> > postprocessing the result again.
> >
> > regards
> >
> > Georg
> >
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers