[java]
Table person = new Table(“person”);
return select(person.star()).
from(person).
orderBy(person.column(“name”));
[/java]
[java]
Table person = new Table(“person”);
Column age = person.column(“age”);
return select(person.star()).
from(person).
where(age.lessThan(25))
[/java]
[java]
Table person = new Table(“person”);
Column wage = person.column(“wage”);
return select(count(person.star())).
from(person).
where(wage.greaterThan(52000))
[/java]
magpiebrain 
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:
p. > I would suggest to next think about whether being faithful to the form of SQL is bringing clarity to the code.
p. 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.
p. > Also why are you obtaining the column from the person directly, when the column is unambiguous
p. 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.
p. > And if you don’t mind restricting to JDK5…where ‘table’ and ‘column’ are statically imported methods
p. 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).