[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query kernel objectsOfClass
I agree with Falko's earlier comment that querying should not be based on
objectsOfClass. Using objectsOfClass as the source collection the query
operates on effectively 'flattens' the object hierarchy.
I thought of two alternatives:
1. Creating a Query class similar to that defined in JDO.
In this approach the source collection is passed to the Query as a
parameter. With Ozone this creates a performance problem unless the Query is
an persistent OzoneObject. Implementing indexes appears problematic.
2. Defining a Queryable interface that could be implemented in collections
that would be the source for queries.
The interface would include methods such as 'selectObjects(someFilter)'. The
interface might also include methods such as 'createIndex(fieldName)' with
the implementation automaticaly managing the index and utilizing it to
optimize queries.
With the Queryable interface approach the source collections for queries are
normally occuring collections in the object hierarchy. For example:
aCustomer.getInvoices().selectObjects("id = 1234").
The filter example "id = 1234" is not a proposal for the filter format. It's
just simple to understand at a glance. Note that if one was using
objectsOfClass for a source collection that the query would have to traverse
every invoice object in the database.
Comments?
Don
>From: Falko Braeutigam <falko@smb-tec.com>
>Reply-To: ozone-dev@ozone-db.org
>To: Dasarathi <dasar@tetra.iitm.ernet.in>
>CC: ozone-dev@ozone-db.org
>Subject: Re: Query kernel objectsOfClass
>Date: Sat, 14 Apr 2001 18:00:29 +0200
>
>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
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.