From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, T_FILL_THIS_FORM_SHORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ee0dc912649d50d4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada DB bindings and APQ Date: Wed, 15 Dec 2004 18:43:09 +0100 Organization: cbb software GmbH Message-ID: <1x4xxn0yx1abu.myr2odcsdxg8$.dlg@40tude.net> References: <1km3c584awura$.y7djkir1ozya$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net 4cmp/gqLEc8z7vBWCCU6aQfCN+VeP/jI1KscwzMwBy93S8B/w= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:6971 Date: 2004-12-15T18:43:09+01:00 List-Id: On Wed, 15 Dec 2004 10:26:37 +1100, Brian May wrote: >>>>>> "Dmitry" == Dmitry A Kazakov 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