David Masover
9/26/2008 1:33:00 AM
On Thursday 25 September 2008 18:43:31 John Carter wrote:
> But when it comes down to it, SQL wins for certain tasks, and
> ruby/perl/python wins for other tasks.
The tasks SQL wins for, it wins mostly because it is executed inside the
database engine. I doubt very much that, given the choice between writing SQL
and writing Ruby, I would rather write SQL.
CouchDB will let me write custom queries in JavaScript.
And there was a similar, Ruby-based project (rddb?), but I haven't seen any
activity there in awhile. Still, the idea is the same -- I can write queries
in pure ruby.
> at some primitive level... the query is written as a string, the
> string is fed to a SQL interpreter, the query is optimized by the SQL
> engine and the results returned.
In other words, you're wanting to fundamentally change the language -- syntax,
parser, interpreter, top to bottom -- for a performance hack, to make it
perform better with SQL databases.
SQL databases aren't the only kind of database, nor is a database the only way
to store data. Nor is SQLite the only SQL database, or necessarily the best
to optimize for.
> Suggestion to make Ruby the undisputed leader of the scripting languages...
I don't think any of the other scripting languages are suffering greatly
because of lack of SQL.
In fact, Ruby has more often been slower than other languages, in my
experience. Often several orders of magnitude slower than Python, for
instance -- and Python does have Django.
Consider that -- Ruby sees plenty of production use _despite_ being slow.
> 1) Extend Ruby syntax to accept a useful subset of SQLite SQL.
Sequel does this, somewhat. So does ActiveRecord, for that matter.
Neither of which is bound to one database engine.
Now, yes, they currently generate strings, at some point. However, since you
don't have to directly interact with the strings, your step 2 is nothing more
than a performance hack, which only applies to SQLite.
> 4) provide a means of transparently mapping certain classes to
> tables so that they are automagically persisted at commit points,
> on garbage collection or program exit, and automagically
> revivified on reference.
In other words, an ORM.
Like ActiveRecord, DataMapper, Og, Sequel, etc.
Only difference you're proposing is to make the persistence transparent.
Programmers working with ActiveRecord, in particular, don't seem to think
about concurrency issues enough -- how many of us actually use transactions?
But you're suggesting we bury that problem even further in abstractions.
What happens when two programs try to access the same object?
> 5) Hide the distinction between Object "handles" and foreign
> keys.
Yeah, like ActiveRecord, DataMapper...
The foreign keys are there if you need them, but you don't have to deal with
them directly.
> # It's persisted, so even if this appears a useless and can be garbage
> # collected, it will at least be added to Customer table
> Customer.new( "Joe Blogs", "52 hell", "Doggcity")
Great -- what happens if, somewhere very soon after this point, an exception
is raised? What about validations?
Never mind that it's kind of ugly that you're using positional arguments
there...
In a modern ORM, I'd do something like:
cust = Customer.new( :name => 'Joe blogs')
cust.save!
Maybe an address wasn't required, and this will work. Maybe an address was
required, in which case, an exception will be raised, and the record won't be
saved. It's useful to separate this from creation for other reasons, too --
suppose I did provide an address, and now want to remove it:
cust = Customer.find_by_name 'Joe blogs'
cust.address = nil
cust.save!
In this case, again, if address was required, I'll get a validation error, and
this particular change to the record won't be saved.