Re: S.O.D.A. database Query API - call for comments

JRStern wrote:

> >we are working on an API to query databases.
>
> Sounds like a wonderful project to reinvent the wheel.

I think we are working on something new.

Some major differences to SQL for the moment:
- We are creating an API, not a query language. The API will allow to create
queries step-by-step with many small functions.
- Query-By-Example is part of the concept.

• Joins are expressed by the structure of classes. They do not need to be repeated within the query language.
• Object-oriented queries understand object-oriented language concepts like inheritance.
• The query will not return a flat table. It will return objects. The objects will be linked together in the same way as they were stored. Complex tree structures will be preserved.
• Queries will also allow to reference objects by identity.
• The size of the resultset will be available.

Some ideas for the future:
- A callback interface for programmatic constraints.

• Fuzzy evaluation. "Get me the best 20 matches".
• Very tight language bindings. Queries to contents of HashMaps for instance.

Extending an API is very simple. You just add another function. Extending SQL is a crime. ;-)

> Do you understand anything about joins, groups, subqueries, much less > cursors and stored procedures?

Yes.
Counting the years, I have more experience with relational databases than with object databases.

• Joins are modelled by the class structure. They are not necessary.
• GROUP BY will be skipped for the time being. A groupBy() function would fit into the current concept though. Some groupBy() functionality is automatically there since objects are automatically grouped by their ancestors. Of course there are lots of usecases like the analysis of time periods that make groupBy worthwhile.
• Most subquery functionality is covered by the current design.
• Cursors? What for? Instantiation- and execution-control is behind the API. The resultset (ObjectSet) is an Iterator type of object. Vendors can implement it like a cursor. Furthermore there is no need for a language- or variable-binding since the query language is the programming language.
• Stored procedures typically are not clean OO logic. The future concept of callback functions is very similar to stored procedures though.

> I know, these things tend to make
> object guys uncomfortable, but if you don't handle them, you probably
> never really understood the problem in the first place.

There is no "the" problem.
There are lots and lots of different problems. This is why I have asked for help and input here.

Judging from your mail, you have not had a single look at our first design yet.
It is downloadable from:
http://www.odbms.org/soda/soda.zip

Thank you for your comments.

Kind regards,
Carl Received on Sat Jul 21 2001 - 19:59:56 CEST