Re: Call for an API standard for SQL statements

"Laconic2" <laconic2_at_comcast.net> wrote:
> Do you really need custom datatypes, or just custom domains?
There are no database vendor-independent domain concept. Anyway, I really need the column values to be mapped to custom classes in my programming language. Treating the data as string, numbers or dates is not enough.

> Does your DBMS support CREATE DOMAIN? If not, why not?
I know that RDB support this, but Oracle does not.

> > A second extremly useful feature is converting a two-dimensional query
> > result into a hierachical view. Lets say that we have a query joinin
> > the tables "Order" and "OrderDetail". My framework returns a list of
> > "Order" records, but calling the method "getRelatedRecords" on such
> > instance, will return a list of "OrderDetail" records. This feature is
> > only possible if the framework has knowledge about wich tables are
> > participating in the query.
>
> Gee, I never had any trouble doing this with the Datatrieve report writer,
> way back in 1982!
Yes, but most report engines I know of need a report definition there you tell how to join tables and how to group the result. Otherwise they have to parse the SQL string.

> Have later report writers become less competent?
No, I think that many old good concepts have been abandoned the last 15 years. Looking back in the past can give us many useful ideas.

> > A third example is data-aware GUI components. Lets say we want to make
> > a search panel which takes a query object, builds a GUI and let the
> > user fill in the parameters. This is of course only possible if we
> > have have a query object.
>
> I'm not sure about this.
What are you not sure about? That is a good idea this automatically built search panels, or that an object model is needed to do this?

> Why wouldn't it be easier to translate back and forth between standard SQL
> and the vendor's dialect SQL?
It is not easier because first you need to do parsing of the standard SQL. After the parsing phase you will have an object structure representing the statemenet.

There are also one more important reason for creating the query as an object instead of a string. Using a string, you can never check the syntax before runtime. But using object representation, syntax errors will be detected during compilation.

Fredrik Bertilsson
http://butler.sourceforge.net Received on Fri Oct 22 2004 - 07:22:22 CEST