Re: JDO Query Specification

I'm submitting a public comment along similar lines. I'm using systems with do both String filters and object filters. The object filters are a little less dynamic, but provide excellent performance and all the flexibility needed. StoredObjects (www.jdbms.org) has an excellent implementation of the latter. Requiring one to parse a string to do a query can be a severe limitation, in my experience. It might be nice to be able to do this under some circumstances, but it also is good not to have to give up the idea of Object filters.

"Carl Rosenberger" <carl_at_db4o.com> writes:

> Hi all,
> tomorrow, July 5th, is the last day for public review of Sun's Java Data
> Object specification.
> http://access1.sun.com/jdo/
>
> JDO could be the key concept for the breakthrough of object databases.
>
> If that could be of importance to you, I would be interested to hear your
> opinion on the following mail I just sent:
>
>
> > Please have another close look at the query interface.
> >
> > In my opinion String parameters are not a good choice.
> > Disadvantages for application developers:
> > - Typechecking will not be available at design time.
> > - If existing instances of objects are used to generate query parameters,
 an
> > extra step to transfer them to Strings will be necessary.
> > Disadvantages for JDO vendors:
> > - The coding effort to evaluate queries will either include String parsing
> > or a creation of Java Classes and compilation during runtime.
> >
> > I would prefer the simplest possible object-oriented way to express a
 query:
> >
> > 1. Template
> > Query criteria are described by template objects.
> > Any PersistenceCapable object can be used as a template object.
> > All non null fields of a template object are used as query criteria.
> > Instantiated fields of the template also describe the depth of the desired
> > instantiation for retrieval.
> >
> > 2. Query
> > An unlimited number of template objects can be joined together to make up
 a
> > Query. This is done by calling
> > Query.and(PersistenceCapable templateObject)
> > or
> > Query.or(PersistenceCapable templateObject)
> > The order of adding denotes the order of evaluation.
> >
> > An optional parameter describes the desired processing info for the newly
> > added template.
> > "==" is default.
> > Options: "!=", ">", "<", ">=", "<=", "orderby", "contains", "group",
 "sum",
> > average", "maximum", "minimum" ...and more
> >
> >
> > Two queries can be joined by
> > Query1.and(Query2)
> > or
> > Query1.or(Query2)
> >
> > Query1.subQuery(Query2) makes Query2 a subquery of Query1
> >
> > 3. Execute
> > Collection = PersistenceManager.execute(Query)
> > No additional parameters have to be supplied.
> >
> > Simplicity rules!
> >
> > I will be happy to supply code examples if I have left any points unclear.
> >
> > My implementation will support a simple shortcut version of the above:
> > Collection = PersistenceManager.get(PersistenceCapable templateObject)
> >
> > I would be delighted to participate in a further specification of this
> > concept.
> >
> > Please excuse conceptional mistakes, but I had to make the 5th of July
> > deadline.
> >
> > Regards,
> > Carl Rosenberger
> > db4o - database for objects - http://www.db4o.com
>
>
>
 

-- 
David Forslund				 Voice:(505) 665-1907
Advanced Computing Laboratory, MSB287	 FAX: (505) 665-4939
Los Alamos National Laboratory		 EMAIL: dwf_at_lanl.gov
Los Alamos, NM 87545			 WWW: http://www.acl.lanl.gov/~dwf