views:

766

answers:

8

I'm writing a server that I expect to be run by many different people, not all of whom I will have direct contact with. The servers will communicate with each other in a cluster. Part of the server's functionality involves selecting a small subset of rows from a potentially very large table. The exact choice of what rows are selected will need some tuning, and it's important that it's possible for the person running the cluster (eg, myself) to update the selection criteria without getting each and every server administrator to deploy a new version of the server.

Simply writing the function in Python isn't really an option, since nobody is going to want to install a server that downloads and executes arbitrary Python code at runtime.

What I need are suggestions on the simplest way to implement a Domain Specific Language to achieve this goal. The language needs to be capable of simple expression evaluation, as well as querying table indexes and iterating through the returned rows. Ease of writing and reading the language is secondary to ease of implementing it. I'd also prefer not to have to write an entire query optimiser, so something that explicitly specifies what indexes to query would be ideal.

The interface that this will have to compile against will be similar in capabilities to what the App Engine datastore exports: You can query for sequential ranges on any index on the table (eg, less-than, greater-than, range and equality queries), then filter the returned row by any boolean expression. You can also concatenate multiple independent result sets together.

I realise this question sounds a lot like I'm asking for SQL. However, I don't want to require that the datastore backing this data be a relational database, and I don't want the overhead of trying to reimplement SQL myself. I'm also dealing with only a single table with a known schema. Finally, no joins will be required. Something much simpler would be far preferable.

Edit: Expanded description to clear up some misconceptions.

A: 

Why not create a language that when it "compiles" it generates SQL or whatever query language your datastore requires ?

You would be basically creating an abstraction over your persistence layer.

mmattax
The server architecture allows for multiple possible datastore implementations. The simplest possible one is a simple in-memory table, so the query language my datastore requires is, well, Python.
Nick Johnson
A: 

You mentioned Python. Why not use Python? If someone can "type in" an expression in your DSL, they can type in Python.

You'll need some rules on structure of the expression, but that's a lot easier than implementing something new.

Will Hartung
I already said why: Nobody is going to want to run a server that downloads and executes arbitrary code at runtime. And a parser that can check Python thoroughly enough to ensure it's doing nothing malicious is likely to be nearly as complicated as writing a proper DSL anyway.
Nick Johnson
But that's a security issue that can be managed. For example, you DBA can download arbitrary code at runtime. Considering how rare this process seems to be, no reason it can't be done by someone trusted to do the work.
Will Hartung
The whole point is that it can't require manual intervention from each server administrator. I need a DSL that's capable of querying/filtering in this fashion, but that server administrators can trust to be updated without their intervention or supervision.
Nick Johnson
A: 

You said nobody is going to want to install a server that downloads and executes arbitrary code at runtime. However, that is exactly what your DSL will do (eventually) so there probably isn't that much of a difference. Unless you're doing something very specific with the data then I don't think a DSL will buy you that much and it will frustrate the users who are already versed in SQL. Don't underestimate the size of the task you'll be taking on.

To answer your question however, you will need to come up with a grammar for your language, something to parse the text and walk the tree, emitting code or calling an API that you've written (which is why my comment that you're still going to have to ship some code).

There are plenty of educational texts on grammars for mathematical expressions you can refer to on the net, that's fairly straight forward. You may have a parser generator tool like ANTLR or Yacc you can use to help you generate the parser (or use a language like Lisp/Scheme and marry the two up). Coming up with a reasonable SQL grammar won't be easy. But google 'BNF SQL' and see what you come up with.

Best of luck.

Phil Bennett
Yes, it'll download 'arbitrary' code, but when it's expressed in terms of this DSL, it can't do much. There's a world of difference between arbitrary Python code and an arbitrary filter expression (or similar).
Nick Johnson
+1  A: 

I think we're going to need a bit more information here. Let me know if any of the following is based on incorrect assumptions.

First of all, as you pointed out yourself, there already exists a DSL for selecting rows from arbitrary tables-- it is called "SQL". Since you don't want to reinvent SQL, I'm assuming that you only need to query from a single table with a fixed format.

If this is the case, you probably don't need to implement a DSL (although that's certainly one way to go); it may be easier, if you are used to Object Orientation, to create a Filter object.

More specifically, a "Filter" collection that would hold one or more SelectionCriterion objects. You can implement these to inherit from one or more base classes representing types of selections (Range, LessThan, ExactMatch, Like, etc.) Once these base classes are in place, you can create column-specific inherited versions which are appropriate to that column. Finally, depending on the complexity of the queries you want to support, you'll want to implement some kind of connective glue to handle AND and OR and NOT linkages between the various criteria.

If you feel like it, you can create a simple GUI to load up the collection; I'd look at the filtering in Excel as a model, if you don't have anything else in mind.

Finally, it should be trivial to convert the contents of this Collection to the corresponding SQL, and pass that to the database.

However: if what you are after is simplicity, and your users understand SQL, you could simply ask them to type in the contents of a WHERE clause, and programmatically build up the rest of the query. From a security perspective, if your code has control over the columns selected and the FROM clause, and your database permissions are set properly, and you do some sanity checking on the string coming in from the users, this would be a relatively safe option.

Michael Dorfman
Mostly sound, but I still need some way to specify the filter collection etc. Bear in mind that the goal here is for me to be able to specify an updated function and have it propagate to all the servers in a cluster.
Nick Johnson
A: 

It really sounds like SQL, but perhaps it's worth to try using SQLite if you want to keep it simple?

Nouveau
+1  A: 

"implement a Domain Specific Language"

"nobody is going to want to install a server that downloads and executes arbitrary Python code at runtime"

I want a DSL but I don't want Python to be that DSL. Okay. How will you execute this DSL? What runtime is acceptable if not Python?

What if I have a C program that happens to embed the Python interpreter? Is that acceptable?

And -- if Python is not an acceptable runtime -- why does this have a Python tag?

S.Lott
I'll execute the DSL by writing an interpreter in Python. That's why it has the Python tag. The whole point of using a DSL in this case is that it won't allow code written in it to break out of the sandbox and affect the system as a whole.
Nick Johnson
A: 

It sounds like you want to create a grammar not a DSL. I'd look into ANTLR which will allow you to create a specific parser that will interpret text and translate to specific commands. ANTLR provides libraries for Python, SQL, Java, C++, C, C# etc.

Also, here is a fine example of an ANTLR calculation engine created in C#

David Robbins
It's more than just a grammar - I need to not just parse it, but to execute it, which makes it a complete DSL. The example of the 'calculation engine' just has the execution code embedded in the parser.
Nick Johnson
+3  A: 

Building a DSL to be interpreted by Python.

Step 1. Build the run-time classes and objects. These classes will have all the cursor loops and SQL statements and all of that algorithmic processing tucked away in their methods. You'll make heavy use of the Command and Strategy design patterns to build these classes. Most things are a command, options and choices are plug-in strategies. Look at the design for Apache Ant's Task API -- it's a good example.

Step 2. Validate that this system of objects actually works. Be sure that the design is simple and complete. You're tests will construct the Command and Strategy objects, and then execute the top-level Command object. The Command objects will do the work.

At this point you're largely done. Your run-time is just a configuration of objects created from the above domain. [This isn't as easy as it sounds. It requires some care to define a set of classes that can be instantiated and then "talk among themselves" to do the work of your application.]

Note that what you'll have will require nothing more than declarations. What's wrong with procedural? One you start to write a DSL with procedural elements, you find that you need more and more features until you've written Python with different syntax. Not good.

Further, procedural language interpreters are simply hard to write. State of execution, and scope of references are simply hard to manage.

You can use native Python -- and stop worrying about "getting out of the sandbox". Indeed, that's how you'll unit test everything, using a short Python script to create your objects. Python will be the DSL.

["But wait", you say, "If I simply use Python as the DSL people can execute arbitrary things." Depends on what's on the PYTHONPATH, and sys.path. Look at the site module for ways to control what's available.]

A declarative DSL is simplest. It's entirely an exercise in representation. A block of Python that merely sets the values of some variables is nice. That's what Django uses.

You can use the ConfigParser as a language for representing your run-time configuration of objects.

You can use JSON or YAML as a language for representing your run-time configuration of objects. Ready-made parsers are totally available.

You can use XML, too. It's harder to design and parse, but it works fine. People love it. That's how Ant and Maven (and lots of other tools) use declarative syntax to describe procedures. I don't recommend it, because it's a wordy pain in the neck. I recommend simply using Python.

Or, you can go off the deep-end and invent your own syntax and write your own parser.

S.Lott
All good suggestions, but I'm still looking for a suggestion of an effective syntax or format. Procedural or declarative? How best to handle cursors? Etc.
Nick Johnson
Edited to respond to these two points. Declarative. SQL Cursor Loops are in the core classes.
S.Lott