RE: A sequence, by any other name
> -----Original Message-----
> From: Jonas Temple [mailto:jktemple at yhti.net]
> - Include the data type as part of the TABLEDEF information, as you
> stated you are considering.
I'll probably add a second field to TABLEDEF: DATATYPES or some such. I'm
also automating the table/field creation process somewhat, so the user
should never have to touch TABLEDEF directly. Once indices come along,
there will be another system table: INDEXDEF, to keep track of indexed
fields. This should speed up queries over large databases MUCH faster.
> - Since ODBC doesn't handle sequences how about the EUSQL/EDS ODBC
> driver expand the record down to the lowest sequence? Heck, you could
> even write the ODBC driver for EDS and not have to continue to support
> EUSQL.
Well, the only problem with that is that ODBC drivers give you access to the
DBMS. Unfortunately, there isn't really anything comparable to a DBMS for
EDS (EuSQL notwithstanding :). I'll still need to have the code for EuSQL
to do the manipulations.
> For example, take the following sequence:
>TABLEDEF:
>{{{"First Name"},{"Last Name"}},{{"123"},{"456"},{"7890"}}}
> Full Name Phone numner
>a select * would return:
>{"First Name", "Last Name", "123", "456", "7890"}
I thought about doing this, but opted for the simplicity of returning "*",
since there could be many nested sequences. I'd need to flatten out the
record, which might be a good idea.
> Anyway, to sum up what my previous post said, my thoughts are:
> - When returning the field defenitions return the "lowest" field
> definition. In other words, don't return the name of a sequence that
> contains other sequences.
> - When returning the data elements return the "lowest" field value.
Yep, that's basically what I'm thinking.
> Oh by the way, I looked at the documentation on MSDN and ran
> screaming
> when I saw the specifics about writing an ODBC driver. I
> think it would
> be great to have and EDS ODBC driver but the sequence thing will be a
> hurdle. Like I rambled in my other post, you could stop supporting
> EUSQL and go to strictly ODBC. However, some non-Windows folks might
> still want EUSQL.
Since the code would all be in Eu, it should be portable to linux as an .so,
at least. I also just fixed a bug regarding the handling of conditions. It
wasn't looking at the correct fields if all fields in a table weren't
consecutive in the SQL statement (ie, if there was a field from another
table mixed in the order).
Matt Lewis
|
Not Categorized, Please Help
|
|
