On Thu, 06 Oct 2011 10:44:42 +0100, Regan Heath
wrote:
On Wed, 05 Oct 2011 16:44:31 +0100, Andrei Alexandrescu
wrote:
On 10/5/11 10:27 AM, Regan Heath wrote:
I understand the issue, and the point you're making below, and I agree
completely. At the same time, this particular change being
On 2011-10-06 12:25, Regan Heath wrote:
It's obvious from my last post that I think a change should be allowed.
I think you'd agree, were it not for the urgent need of other library
components.
I've been lurking and contributing to this news group on and off for
years (since 2005/2006, maybe ear
On 10/6/11 5:25 AM, Regan Heath wrote:
I've been lurking and contributing to this news group on and off for
years (since 2005/2006, maybe earlier). But, in all that time I have
contributed nothing to Phobos. I have contributed a set of
digest/hashing routines to Tango, because at the time Phobos
Andrei,
Are there guidelines for the Phobos process?
I have put a fair amount of work, two years ago and recently, into a piece for
accessing MySQL via D. I'm looking at this as a bottom-up investigation into
what
might be a more generalized interface for database access.
I've got to the point
On Thu, 06 Oct 2011 15:47:03 +0100, Andrei Alexandrescu
wrote:
On 10/6/11 5:25 AM, Regan Heath wrote:
I've been lurking and contributing to this news group on and off for
years (since 2005/2006, maybe earlier). But, in all that time I have
contributed nothing to Phobos. I have contributed a
Regan Heath Wrote:
> That's just it however, I am not generous enough with my time to be of use
> to you/D/phobos. I spend my free time doing other things, and not working
> on the code I have which could be of use. I suspect there are quite a
> number of people out there who are just like
Steve Teale Wrote:
> Andrei,
>
> Are there guidelines for the Phobos process?
>
> I have put a fair amount of work, two years ago and recently, into a piece for
> accessing MySQL via D. I'm looking at this as a bottom-up investigation into
> what
> might be a more generalized interface for data
On 10/6/11 10:27 AM, Steve Teale wrote:
Andrei,
Are there guidelines for the Phobos process?
We follow the Boost review process:
http://www.boost.org/community/reviews.html
I have put a fair amount of work, two years ago and recently, into a piece for
accessing MySQL via D. I'm looking at
"Andrei Alexandrescu" wrote in message
news:j6ljvs$1if5$1...@digitalmars.com...
>
> For D in particular, I think the range aspect is secondary. Probably it
> will be more important to interoperate with Variant. Most APIs store
> columns in a Variant structure that captures all possible types of
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:j6ljvs$1if5$1...@digitalmars.com...
For D in particular, I think the range aspect is secondary. Probably it
will be more important to interoperate with Variant. Most APIs store
columns in a Variant structure that captures all p
On 10/6/11 8:55 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:j6ljvs$1if5$1...@digitalmars.com...
For D in particular, I think the range aspect is secondary. Probably it
will be more important to interoperate with Variant. Most APIs store
columns in a Variant structure
Andrei,
I was thinking the same thing about the C level interface sometime in the middle
of last night. A straight translation of mysqld could be put there almost
immediately. I have to make myself translate the character set stuff, and add
that, but it's probably only a days work.
As for the int
On 2011-10-06 21:44, Jesse Phillips wrote:
Regan Heath Wrote:
That's just it however, I am not generous enough with my time to be of use
to you/D/phobos. I spend my free time doing other things, and not working
on the code I have which could be of use. I suspect there are quite a
number of pe
On 2011-10-07 03:17, Andrei Alexandrescu wrote:
On 10/6/11 10:27 AM, Steve Teale wrote:
Andrei,
Are there guidelines for the Phobos process?
We follow the Boost review process:
http://www.boost.org/community/reviews.html
I have put a fair amount of work, two years ago and recently, into a
p
On 2011-10-07 04:56, Piotr Szturmaj wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:j6ljvs$1if5$1...@digitalmars.com...
For D in particular, I think the range aspect is secondary. Probably it
will be more important to interoperate with Variant. Most APIs store
columns
On 2011-10-07 07:24, Steve Teale wrote:
Andrei,
I was thinking the same thing about the C level interface sometime in the middle
of last night. A straight translation of mysqld could be put there almost
immediately. I have to make myself translate the character set stuff, and add
that, but it's
On Fri, 2011-10-07 at 08:49 +0200, Jacob Carlborg wrote:
[ . . . ]
> I think it's important to support the range interface (or if it's
> simpler, the array interface). I think ActiveRecord has a good high
> level API which allows to lazily evaluate SQL queries.
>
> persons = Person.all # no quer
On Fri, 2011-10-07 at 08:51 +0200, Jacob Carlborg wrote:
[ . . . ]
> I think it's important to have a solid low level database API which an
> object oriented abstraction can be built upon.
Why object oriented? Why not functional?
The lesson form ORMs is that object oriented and relational can be
Am 07.10.2011, 09:26 Uhr, schrieb Russel Winder :
On Fri, 2011-10-07 at 08:49 +0200, Jacob Carlborg wrote:
[ . . . ]
I think it's important to support the range interface (or if it's
simpler, the array interface). I think ActiveRecord has a good high
level API which allows to lazily evaluate SQ
On 2011-10-07 09:30, Russel Winder wrote:
On Fri, 2011-10-07 at 08:51 +0200, Jacob Carlborg wrote:
[ . . . ]
I think it's important to have a solid low level database API which an
object oriented abstraction can be built upon.
Why object oriented? Why not functional?
The point was that the l
On 2011-10-07 09:26, Russel Winder wrote:
On Fri, 2011-10-07 at 08:49 +0200, Jacob Carlborg wrote:
[ . . . ]
I think it's important to support the range interface (or if it's
simpler, the array interface). I think ActiveRecord has a good high
level API which allows to lazily evaluate SQL queries
On Fri, 07 Oct 2011 07:40:01 +0100, Jacob Carlborg wrote:
On 2011-10-06 21:44, Jesse Phillips wrote:
Regan Heath Wrote:
That's just it however, I am not generous enough with my time to be of
use
to you/D/phobos. I spend my free time doing other things, and not
working
on the code I have
What's the big advantage of
Person.find_all_by_name_and_age("Joe", 15)
over
db.query("select * from people where name = ? and age = ?", "Joe", 15);
The latter is much easier to write in the library and you retain all
the flexibility of sql itself if needed.
On 2011-10-07 15:34, Adam Ruppe wrote:
What's the big advantage of
Person.find_all_by_name_and_age("Joe", 15)
over
db.query("select * from people where name = ? and age = ?", "Joe", 15);
The latter is much easier to write in the library and you retain all
the flexibility of sql itself if ne
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[],
42 matches
Mail list logo
