[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query kernel objectsOfClass
On Sat, 14 Apr 2001, Dasarathi wrote:
> hi falko,
> ok then
> how do u think we should proceed then?
I don't know. If you need the objectsOfClass functionality then implement it.
Have a look at org.ozoneDB.core.admin. This might give you an idea of how to
make your query kernel. The admin interface is provided by AdminImpl. This is
a database object. But unlike ordinary database objects it directly interacts
with the ozone kernel. This should also work for the query kernel. Well, just
an idea.
Falko
>
> das
>
>
>
> On Thu, 12 Apr 2001, Falko Braeutigam wrote:
>
> > On Fri, 13 Apr 2001, Dasarathi wrote:
> > > hi falko,
> > > we want the query kernel to finally support OQL, SQL etc etc
> > > and we thought we will start off with OQL.
> > > and we are not searching on this collection of objects,
> > > we will mostly do pointer traversal.unless u store names of
> > > all objects in a table or something we cant retrieve
> > > without objectsofclass. once this gets over then we can think
> > > of better ways of doing it.
> > > if u think that objectsofclasses is very easy to implement why
> > > dont u write that code such that it is used by the kernel alone.
> >
> > ???
> >
> > Did I state anywhere that objectsOfClass is very easy to implement? I probably
> > lost you here.
> >
> >
> > Falko
> >
> > >
> > > bye
> > > das
> > >
> > >
> > > On Thu, 12 Apr 2001, Falko Braeutigam wrote:
> > >
> > > > On Wed, 11 Apr 2001, Dasarathi wrote:
> > > > > The method objectsOfClass in externalDatabase is not
> > > > > implemented in ozone-6.1.I need it very much for our
> > > > > query kernel work to proceed.
> > > > > If someone has done it mail back
> > > >
> > > > objectsOfClass() was a wrong way in the design of the API and should be finally
> > > > removed from the API. If the query kernel needs this function (and surely many
> > > > others that are not part of the native ozone API) then it has to implement it
> > > > itself. This of course will make the query kernel depend on internal ozone data
> > > > structures and APIs but this (in contrast to a ordinary client program) is no
> > > > problem.
> > > >
> > > > Besides, das, it seems that you are following the way to treat all objects of a
> > > > class as a collection and apply the search on this class collection. Do you
> > > > think this approach is flexible enough to serve as a base for all (at least
> > > > many) query fron-ends? I mean, the Java object model itself doesn't have a
> > > > possibility to treat all objects of a class as collection. Only SQL/OQL and
> > > > related approaches do this...
> > > >
> > > >
> > > > Falko
> > > > --
> > > > ______________________________________________________________________
> > > > Falko Braeutigam mailto:falko@smb-tec.com
> > > > SMB GmbH http://www.smb-tec.com
> > > >
> > > >
> > --
> > ______________________________________________________________________
> > Falko Braeutigam mailto:falko@smb-tec.com
> > SMB GmbH http://www.smb-tec.com
> >
> >
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com