On 2011-10-11 23:31, Andrei Alexandrescu wrote:
On 10/11/11 3:05 PM, Jacob Carlborg wrote:
If we're talking use cases and high level interfaces I would go with
something like:
[snip]
I recommend that everyone take a good look at ActiveRecord in Ruby on
Rails:
http://guides.rubyonrails.org/active_record_querying.html
http://guides.rubyonrails.org/association_basics.html
http://guides.rubyonrails.org/active_record_validations_callbacks.html
I confess the example you gave looks very foreign to me. From consulting
http://guides.rubyonrails.org/active_record_querying.html, I see Ruby's
active records esentially recode relational algebra in Ruby (as for the
constructs the equivalent SQL is shown).
Yes, exactly. The point is to have as much as possible in functions
instead of string literals and have a more Ruby like API than an SQL
looking API.
connection.select("*").from("users");
instead of
connection.execute("select * from users")
Then they wrap everything in an object oriented API.
For a variety of reasons, this would be tenuous in D. One simple reason
is that e.g. lambdas don't offer access to textual representation, which
would be necessary to translate lambda-based conditions into SQL text.
ActiveRecord doesn't support these lambda-based conditions out of the
box. It is possible with the help of plugins, which uses a Ruby parser
to get things done.
I though that it might be possible to do in D, without the use of a
parser. Take this for example:
Post.where(p => p.title == "asd")
"p" would be some kind of object/struct that overloads opDispatch. The
opDispatch method would return an object/struct that overloads opCmp and
opEquals. opCmp/opEquals would then return an object/struct that have
recorded the comparison. The "where" method can then translate it in to
raw SQL.
To this to work opCmp/opEquals need to be able to return a struct or an
object, I don't know if this is possible.
I might be narrow-minded, but I thought we're still looking at writing
and executing good old SQL code.
Andrei
That would of course still be needed. I would consider that interface
sit in the middle layer, above the lower driver level and below a higher
ORM like level.
Everyone is of course free to choose at which layer they want to
interface with the database.
--
/Jacob Carlborg
