Fun with Macros: PINQ to SQLAlchemy

49 views
Skip to first unread message

Haoyi Li

unread,
May 17, 2013, 9:37:55 AM5/17/13
to sqlal...@googlegroups.com
Hey All, 

I asked a few questions here a while ago to get help on a project, and thought it might be interesting to share the result of that project.

PINQ to SQLAlchemy is a shameless clone of .NET's LINQ to SQL, using macros to perform the lifting of code into a SQL query. It lets you write code like this:
# Countries with a land area greater than 10 million square kilometers
print query%((x.name, x.surface_area) for x in db.country if x.surface_area > 10000000)
# [(u'Antarctica', Decimal('13120000.0000000000')), (u'Russian Federation', Decimal('17075400.0000000000'))]
Where the whole thing gets translated into a SQLAlchemy expression language "select" query and shipped over to the database. It basically relies entirely on SQLAlchemy's expression language, using macros to perform a very shallow translation from generator-comprehensions into the expression language's "select" and "where" clauses, as well as nicely binding the tables (e.g. db.country) to properly-scoped names.

I thought it may be of interest to some people; you guys clearly put a lot of thought into the expression language (it's pretty great!) and I think its cool how little work was necessary (~80 LOC) to write a macro that removes much of the remaining syntactic boilerplate.

Hope someone found this interesting!
-Haoyi

Michael Bayer

unread,
May 19, 2013, 8:21:10 PM5/19/13
to sqlal...@googlegroups.com
I checked out Macropy several days ago.   Wondered if there's plans to allow the module grab/AST processing to be more selective?   Example: only parse modules from certain packages/paths.  It seemed as if at the moment, once you import the macro loader it's going to hit all modules unconditionally afterwards (is it still taking advantage of .pyc files?)

interesting project though, good luck with it.


Haoyi Li

unread,
May 19, 2013, 9:02:00 PM5/19/13
to sqlal...@googlegroups.com
Currently our custom import loader scans modules for top level "from aaa.bbb.ccc import macros, ddd, eee, ..." before passing them through our macro expander; hopefully not too many other people will put "macros" first in the list in an import-from statement =D. With only in-band signalling at our disposal, there's always going to be a chance of collision. I actually haven't investigated its behavior with .pyc files. 

It wouldn't be to hard to have it only macro expand certain modules and path, but it doesn't do that now.


--
You received this message because you are subscribed to a topic in the Google Groups "sqlalchemy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy/vAXiq34ZoiI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to sqlalchemy+...@googlegroups.com.
To post to this group, send email to sqlal...@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Reply all
Reply to author
Forward
0 new messages