I/O Reader

In my free time I've been playing around with a few neat ideas. The main one is LINQ inspired querying for PHP. Suffice to say, I have made some very solid progress at this domain-specific language and can now make SQL queries that have complex joins in them. Here an example with some foreshadowing to where I'm going with all of this: http://codepad.org/OEVsQmwt.

Update: My Current progress on PHP LINQ: http://codepad.org/qr9SvC2Y.

• PHP
by Peter Goodman on Jun 7, 2008 @ 11:06pm

Interesting stuff, Peter - can't wait to see what comes of it.

My only concern is that the end result seems just as verbose as writing the SQL directly. Is it more or less of a pain to just deal with the downfalls of having raw SQL in your code?

Although I will be an advocate of minimizing join logic. And also, the fact that it can write XML as well is pretty awesome.

by Chris Dary on Jun 8, 2008 @ 7:07am

The length of the code is a concern of mine. For the basic model building I find it's quite compact, but for queries it still takes a lot to do certain things. Here is my reasoning behind it thus far, aside from it being fun:

• Queries are unambiguous.
• You can focus more on what you want to get at rather than how you want to get there.
• The language is portable to other domains (as I mentioned, my intention is to make it work for XML).
• As you might have found on my blog, I developed an ORM last year, and although I am very happy with it, it does have its flaws. For some things you just want to write a query because it can be ugly fitting it into the model, and with my previous system, one needed to get a record of something from the database in order to access what that model was related to, instead of being able to do all the relations right from the start. So, first, I wanted an SQL-like syntax that is entirely divorced from the database. Second, I wanted it to be restricted to the common uses, such that switching to actual SQL is easy.

• I wanted to make an ORM entirely divorced from the database.

Also, here are some problems with the current system:

• Figuring out the join order isn't cheap. I need to create a dependency graph and then recursively build joins out of it. (this only happens in the compile() function call). That means at some point for it to be decent, I would need to be able to precompile queries (to sql) and store them somewhere. Segue: One thing I was thinking, though, is that for compilation, one would need to provide a unique identifier for a query. This same identifier could be seamlessly used with something like memcached as well.

So yeah, I'm quite excited about where I'm going with this, although some aspects of the syntax still are less desirable than their SQL counterparts. If you have any syntax suggestions, please comment!

by Peter Goodman on Jun 8, 2008 @ 9:08am