Re: Ada DB bindings and APQ

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 15 Dec 2004 10:26:37 +1100, Brian May wrote:

>>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>     Dmitry> That's not OO, yet. It is rather typed vs untyped.
> 
> It seems to me it has all the features of an OO system (encapsulation,
> abstraction, inheritance, etc). Rather the issue is that some design
> decisions have been made that you don't agree with.

I didn't mean APQ, otherwise I wouldn't consider it as a starting point. I
meant only the way of constructing queries. Specifically, that there is no
*typed* difference between "CREATE", "1.35" and "INTEGER". Everything is a
string to append. This is untyped => error prone, uncheckable,
unmaintainable.

> While I can see your point of view in issues such as the query type
> being independent of the query string, I can also understand the
> reasons behind doing it this way, and probably would have done the
> same thing myself.

This the next goal: to map the query semantics to a type hierarchy. As the
previous discussion shown, it seems that people are not much ready to
accept it. Let's do it step by step. (:-))
 
> As far I can tell some of your goals of abstraction, while ideal,
> solutions may require more thought and research in order to make sure
> compatibility with all databases and to ensure your goals really are
> met. For instance, my ideal abstraction layer would completely hide
> the SQL layer completely but maintain the flexibility of the SQL
> layer.

Absolutely, but see above.

> This I think would be really difficult to do, and I am not
> volunteering... It would mean that it could potentially work with any
> database, not just an SQL based database.
> 
> Ok, back on planet Earth now, my sane and reasonable priorities for
> this project would be:
> 
> 1. Factory for creating a connection based on a URL (see my previous
>    message). I would be happy to start working on this if desired
>    (note: I don't claim to be any expert on parsing strings in
>    Ada...).

Parsing is not a problem. But advantage is not clear. Basically you need:

- Server name
- DB name
- User name
- Password
- Port

What would change if we pack all that in one string instead of four + one
number?

Real difference is when ODBC provides some DB identification service which
combines Server name + DB name + port in one DSN. But this cannot be done
on the client side. So if you have no MS influence 

>    (note: with 1 completed the next step some people will demand is
>    plugins so you can support other database without recompilation.

I demand it right now! (:-))

>    I  personally don't think this is worth it at the moment, especially
>    as APQ doesn't hide all differences in different databases).

But this is the primary objective in my view.

> 2. Support for different character sets. I do not know what this would
>    require, but it is a real problem that different database can have
>    different character sets, and making assumptions isn't a good
>    idea. Not only that, but in latest versions of mysql different
>    tables within the same database can have different character
>    sets. At the minimum I guess it should be possible to query what
>    character set a table is encoded with (note: I don't know how to do
>    this). 16 bit UTF support would be nice, but we have UTF8 in the
>    meantime.

Fully agree. Main application areas of DBs are localized. So Unicode is a
must.

> 3. Support for other SQL based databases. Note I have this as the
>    lowest priority...

Only within a stable API framework. Otherwise, adding a new DB would lead
to reworking APIs.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de