Squiggle…
[java]
Table person = new Table(“person”);
return select(person.star()).
[/java]
[java]
Table person = new Table(“person”);
Column age = person.column(“age”);
return select(person.star()).
[/java]
[java]
Table person = new Table(“person”);
Column wage = person.column(“wage”);
return select(count(person.star())).
[/java]
This entry was posted on Sunday, April 2nd, 2006 at 9:09 pm and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
9 Responses to “Squiggle…”
Why?
Looks interesting!
I’ve recently been working with various strongly typed query languages, and ways of creating SQL in OO languages. This looks pretty neat, kind of like a paper I read on SQLDOM.
Do you have any more info?
http://joe.truemesh.com/squiggle/
But the site is currently down…
Well, Joe’s thing was the inspiration, but it’s a different beast – I think we’ll end up calling this Squiggle 2.
More to come this weekend I hope
Looks good Sam, seems like embedded DSL’s are an idea waiting to happen.
It looks like you’ve started from SQL and made a mini embedded DSL. I would suggest to next think about whether being faithful to the form of SQL is bringing clarity to the code. For instance I might eliminate the ‘star’ and do this:
Table person = new Table(“person”);
return select(person)
.orderBy(person.column(“name”));
Also why are you obtaining the column from the person directly, when the column is unambiguous you should be able to do this:
Table person = new Table(“person”);
return select(person).orderBy().column(“name”);
And if you don’t mind restricting to JDK5:
return select(table(“person”))
.orderBy(column(“name”));
where ‘table’ and ‘column’ are statically imported methods.
Stacy Wrote:
> I would suggest to next think about whether being faithful to the form of SQL is bringing clarity to the code.
Our starting point is that this is a DSL for SQL, so we wanted to match SQL very closely at least initially. If we start moving away from standard SQL syntax in our DSL, it may make creating the more complex types harder. Put another way, we want to make sure we can do everything we want matching SQL syntax in the DSL, then we’ll think about deviating from it.
> Also why are you obtaining the column from the person directly, when the column is unambiguous
In that case it is, but in many cases it won’t be. Again, we’re being (perhaps overly) explicit at least in the first draft before considering if a lazier language is something we want (or can) support.
> And if you don’t mind restricting to JDK5…where ‘table’ and ‘column’ are statically imported methods
Currently, all our code operates extends a Query class JMock-style to allow the use of utility methods like table(). That allows people using 1.4 to extend Query, and those using 1.5 to statically import the methods if they want. One Java 5 feature I really would like to use though is variable lists of arguments – currently things like the select() method have to have multiple definitions for one, two, three params then an array. Again, I want to see how far I can get supporting 1.4 (which I have to use on my current job) before deciding if we go the 1.5 only route.
Sorry, I wan’t being faceious… I honestly want to know… Why?
I did some experimenting with Squiggle a while ago and I do like the concept. It’s a tough problem to solve since you want to allow for the most important constructs while remaining readable and 1.4 compatible. I’d say ditch the 1.4 syntax and go for Java 5 features. It will improve readability and ease-of-use. When I was playing with Squiggle, I extended it to allow for in-line queries and some other features that were missing from Joe’s initial implementation. If you are interested download my code from http://springdeveloper.com/downloads/Squiggle-plus-dev.zip
Robert Baillie Wrote:
> Sorry, I wan’t being faceious… I honestly want to know… Why?
Given the lack of context to the why, I’m going to assume the ‘why?’ applied to Squiggle, rather than my blog in general :-)
I’m working under the assumption that you yourself have had to invoke SQL from a Java program (this seems to be a safe assumption given the nature of your own blog). Unless you always use a third-party ORM layer (e.g. JDO, Hibernate, TopLink, iBatis) then you’ve probably had to craft SQL. In Java, you either write an API to write the SQL for you (e.g. Squiggle) or you write it in strings.
Unlike the original squiggle – which used a setter based API – Squiggle 2(or whatever we end up calling this) – aims to create a Java API that is as close to SQL as possible, to make it easy to write. As Stacy correctly pointed out, if Squiggle is done right it’ll be a Domain Specific Language for SQL in Java.
Avoiding a discussion of the pros and cons of DSLs in general, in this case you’ll get keyword completion in your Java code when writing a squiggle statement, and the nature of the API will make it much harder for you to make a mistake when creating SQL (something which can’t be said for specifying your SQL in a string).
Have your say
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:
URIs must be fully qualified (eg: http://www.domainname.com) and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.