Further generic question. (Yes, I am listening to the answers too)

If some underlying databases don't support the features that our chosen interface requires, do we attempt to synthesize them - presumably at cost to performance, or do we just throw a compile-time exception that basically tells the user to use a lower interface and code it themself?

It's important that we establish such boundaries. Otherwise we'll never ever have an alpha version of 0.1.

To express a personal opinion, then as a first pass we should do something that is at about the same level as JDBC but without the concessions to DBs like Postgres that have fancy SQL types.

When we have decided on an interface, we can always go forward, but going back is embarrassing.

Steve

The way I'd do it is:

interface Database {
  // support shared functions here, and other stuff useful enough to
  // warrant emulation
}

class Postgres : Database {
  // implement the interface, of course, but also all other postgres
  // specific stuff
}


When you go to use it, if you're  happy with the basics, declare Databases.

If you need something special, use Postgres objects.

Adam Ruppe wrote:
> The way I'd do it is:
>
> interface Database {
>    // support shared functions here, and other stuff useful enough to
>    // warrant emulation
> }
>
> class Postgres : Database {
>    // implement the interface, of course, but also all other postgres
>    // specific stuff
> }
>
>
> When you go to use it, if you're  happy with the basics, declare
> Databases.
>
> If you need something special, use Postgres objects.

+1

Steve Teale wrote:
> To express a personal opinion, then as a first pass we should do
> something that is at about the same level as JDBC but without the
> concessions to DBs like Postgres that have fancy SQL types.

I disagree. Doing it this way may introduce difficulties or incompabilities in the future. I think we should design it from the ground up, keeping in mind the all databases.

We probably should write a page on a wiki describing the API, without actually implementing anything. Then anyone involved may contribute to its design, so it may evolve into somewhat more thought out API.

> We probably should write a page on a wiki describing the API, without actually implementing anything. Then anyone involved may contribute to its design, so it may evolve into somewhat more thought out API.

I like that idea! Must find out how to put up a wiki.

Steve

Steve Teale wrote:
>> We probably should write a page on a wiki describing the API, without
>> actually implementing anything. Then anyone involved may contribute to
>> its design, so it may evolve into somewhat more thought out API.
>
> I like that idea! Must find out how to put up a wiki.

Or use existing one: http://www.prowiki.org/wiki4d/wiki.cgi

:-)

On 10/9/11 11:15 AM, Steve Teale wrote:
> If using variants for a set of out parameters you must have something
> equivalent to:
>
> Variant[3] va;
> va[0] = cast(byte) 0;
> va[1] = 0.0F;
> va[2] = cast(char[]) [];
>
> So you have to have exactly the same information at compile time for the
> Variant array as you do for the struct - you still have to specify a set
> of types.

Not at all, fortunately it's much simpler than that. Far as I can tell, a resultset emitted by a DBMS comes in the form of data (either untyped buffers or strings) plus column type information, usually in the form of an enumeration (e.g. 0 for NULL, 1 for int, 2 for double, 3 for string etc). You of course also have the total column count. So all you need to do is use that enum to pour the data into the Variants.

See this for example:

http://msdn.microsoft.com/en-us/library/ms131297.aspx

You can glean all needed information from the resultset after having issued the query.

> It's probably true to say that the syntax/semantics of the interface will
> suck slightly more in the Variant case than in the struct case.

That's a given. The suckiness won't come, however, in the form of additional trips to the database.


Andrei

On 10/9/11 11:40 AM, Steve Teale wrote:
> Further generic question. (Yes, I am listening to the answers too)
>
> If some underlying databases don't support the features that our chosen
> interface requires, do we attempt to synthesize them - presumably at cost
> to performance, or do we just throw a compile-time exception that
> basically tells the user to use a lower interface and code it themself?

No.

Andrei

On 10/9/11 11:54 AM, Adam Ruppe wrote:
> The way I'd do it is:
>
> interface Database {
>    // support shared functions here, and other stuff useful enough to
>    // warrant emulation
> }
>
> class Postgres : Database {
>    // implement the interface, of course, but also all other postgres
>    // specific stuff
> }
>
>
> When you go to use it, if you're  happy with the basics, declare
> Databases.
>
> If you need something special, use Postgres objects.

Makes sense. JDBC does that, too.

Andrei

On 2011-10-09 18:54, Adam Ruppe wrote:
> The way I'd do it is:
>
> interface Database {
>    // support shared functions here, and other stuff useful enough to
>    // warrant emulation
> }
>
> class Postgres : Database {
>    // implement the interface, of course, but also all other postgres
>    // specific stuff
> }
>
>
> When you go to use it, if you're  happy with the basics, declare
> Databases.
>
> If you need something special, use Postgres objects.

+1

-- 
/Jacob Carlborg