I'm thinking that for each database that gets covered there will
need to be two modules, like:
etc.c.mysql
etc.mysqld
The etc.c.xxx modules would be completely different between databases -
just translations of the necessary header files. The xxxd modules
would be as similar as possible consisten
On 10/7/11 9:11 AM, Steve Teale wrote:
I'm thinking that for each database that gets covered there will
need to be two modules, like:
etc.c.mysql
etc.mysqld
The etc.c.xxx modules would be completely different between databases -
just translations of the necessary header files. The xxxd modules
On 07-10-2011 16:11, Steve Teale wrote:
I'm thinking that for each database that gets covered there will
need to be two modules, like:
etc.c.mysql
etc.mysqld
The etc.c.xxx modules would be completely different between databases -
just translations of the necessary header files. The xxxd modules
Andrei,
The suggestion in your penultimate paragraph is what I'm trying to get started.
Maybe the answer to the problem with structs may lie somewhere in std.typecons
in
combination with the field discovery features supported by most databases. If we
can manufacture the struct to suit the circum
On 10/7/11 11:51 AM, Steve Teale wrote:
Andrei,
The suggestion in your penultimate paragraph is what I'm trying to get started.
Maybe the answer to the problem with structs may lie somewhere in std.typecons
in
combination with the field discovery features supported by most databases. If we
can
Andrei Alexandrescu wrote:
1. MFC had at a point a wizard that generated one struct per resultset.
It was an absolute maintenance disaster and they recanted by offering
dynamically-bound result sets. The lesson there is that defining a
struct for each query won't likely play out, so we better use
On 10/7/11 12:02 PM, Piotr Szturmaj wrote:
Andrei Alexandrescu wrote:
1. MFC had at a point a wizard that generated one struct per resultset.
It was an absolute maintenance disaster and they recanted by offering
dynamically-bound result sets. The lesson there is that defining a
struct for each q
In my database.d, I used a database row struct to provide both
integer and key based indexes.
Andrei,
I've actually already got that in a way. Before I attempt to populate fields
into
a struct, the struct is checked to see if it conforms to the field properties.
Steve
On Oct 7, 2011, at 8:46 AM, Andrei Alexandrescu wrote:
> On 10/7/11 9:11 AM, Steve Teale wrote:
>> I'm thinking that for each database that gets covered there will
>> need to be two modules, like:
>>
>> etc.c.mysql
>> etc.mysqld
>>
>> The etc.c.xxx modules would be completely different between d
Andrei,
So if I'm understanding you correctly, if structs are used, and there's a
database
change, then the app has to be rebuilt. If Variants, then only the app's config
file has to be updated (or the app can look in the database to get such
information) - have I got this right?
Steve
On Oct 7, 2011, at 10:14 AM, Adam Ruppe wrote:
> In my database.d, I used a database row struct to provide both
> integer and key based indexes.
Funny… I have a ResultSet object which contains an array of Column objects.
Here's the basic idea:
class ResultSet {
static class Column {
On Oct 7, 2011, at 11:27 AM, Steve Teale wrote:
> Andrei,
>
> So if I'm understanding you correctly, if structs are used, and there's a
> database
> change, then the app has to be rebuilt. If Variants, then only the app's
> config
> file has to be updated (or the app can look in the database to
Sean Kelly wote:
> Does your Row equate to the ResultSet above?
Fairly similar.
Mine looks something like this:
interface ResultSet {
// name for associative array to result index
int getFieldIndex(string field);
string[] fieldNames();
bool empty();
Row f
On 2011-10-07 16:11, Steve Teale wrote:
I'm thinking that for each database that gets covered there will
need to be two modules, like:
etc.c.mysql
etc.mysqld
The etc.c.xxx modules would be completely different between databases -
just translations of the necessary header files. The xxxd modules
On 10/7/11 1:27 PM, Steve Teale wrote:
Andrei,
So if I'm understanding you correctly, if structs are used, and there's a
database
change, then the app has to be rebuilt.
Yes. Touched to update the structs and rebuilt.
If Variants, then only the app's config
file has to be updated (or the ap
Andrei Alexandrescu wrote:
On 10/7/11 12:02 PM, Piotr Szturmaj wrote:
Did you see http://pszturmaj.github.com/ddb/db.html ? It maps tuples,
structs and arrays in similar manner.
I did. Looks good. Why do you need DBRow? You could simply use
Variant[], the given struct, or Tuple directly.
Sur
On 10/07/11 15:00, Piotr Szturmaj wrote:
Andrei Alexandrescu wrote:
On 10/7/11 12:02 PM, Piotr Szturmaj wrote:
Did you see http://pszturmaj.github.com/ddb/db.html ? It maps tuples,
structs and arrays in similar manner.
I did. Looks good. Why do you need DBRow? You could simply use
Variant[],
18 matches
Mail list logo
