how to build up the library..

[Jacob Carlborg]

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
>> 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 where I can support a good range of database
>> operations, and
>> present result sets as arrays of D structs, which presumably implies
>> Ranges.
>> There's also lower level stuff to do more complex operations. So I'm
>> wondering if
>> I should take the first process steps. I'm retired, so I do have time
>> to spend on it.
>>
>> The MySQL C api is not what you could call orthogonal - in
>> crystallography terms
>> it is probably Triclinic, so it may not have been the best place to
>> start. There's
>> another guy I've had some correspondence with who is working on
>> Postgres. He's
>> interested in the same idea.
>>
>> What do you think?
>
> I think this is a great initiative. Perhaps it would be nice to have a
> C-level API translation in etc.mysql. Then we should have a driver-style
> interface a la Java's JDBC, Perl's DBI, Python's PEP249 etc.
>
> 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 the
> database.
>
> Resultsets come as input ranges of array of Variant. It's not important
> to make them compatible with the input range interface because it's
> unlikely you'll pass that array of Variant directly to some algorithm.
> That being said, people will naturally expect to use the canonical range
> interface. It would probably be gratuitous to choose other primitive(s)
> than empty/front/popFront.

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 query is performed here
persons = persons.where("name = 'Joe'") # or here

persons.each do |p| # The actual query is performed here
     # do something with each Person
end

I don't think it would be strange to see something like this:

Person.where("age > 10").map{ |p| p.name } # using "map" on an SQL query

-- 
/Jacob Carlborg