[grails-dev] using code visitors

[Dierk König]

Hi guys,

as I currently write the Groovy Sql chapter for the book,
I came across groovy.sql.DataSet and the SqlWhereVisitor.
That approach may also handy in the

>         def user = User.findByName(name)

scenario since it would allow writing it as

User.find { it.name == name }

The SqlWhereVisitor actually works on the AST of the
Closure's expression and generates the SQL WHERE clause
from it.
I just learned about this possibility and I'm really
exited :-)

cheers
Mittie

[graemer]

Whoa.. this could be great! I'll take a look

Graeme

On 01/11/05, Dierk Koenig <[hidden email]> wrote:

> Hi guys,
>
> as I currently write the Groovy Sql chapter for the book,
> I came across groovy.sql.DataSet and the SqlWhereVisitor.
> That approach may also handy in the
>
> >         def user = User.findByName(name)
>
> scenario since it would allow writing it as
>
> User.find { it.name == name }
>
> The SqlWhereVisitor actually works on the AST of the
> Closure's expression and generates the SQL WHERE clause
> from it.
> I just learned about this possibility and I'm really
> exited :-)
>
> cheers
> Mittie
>

[graemer]

Hmm although I was initially excited by this approach I think it does
have limitation as I'm not sure how you would handle variable
resolution. For example you can do:

User.find {
    it.name = "fred"
}

but how would you do? :

def name = "fred"
User.find {
    it.name = name
}

This seems to be impossible unless there is some way to resolve the
variable fred while in the context of visiting the AST. Can you do
this?

The other option is to used named queries like:

def q = User.createQuery {
       it.name = ":name"
}
q.params = [ "name" : "fred" ]
def results = q.find()

Which isn't quite as cool and flexible.. Any thoughts?

Graeme


On 01/11/05, Graeme Rocher <[hidden email]> wrote:

> Whoa.. this could be great! I'll take a look
>
> Graeme
>
> On 01/11/05, Dierk Koenig <[hidden email]> wrote:
> > Hi guys,
> >
> > as I currently write the Groovy Sql chapter for the book,
> > I came across groovy.sql.DataSet and the SqlWhereVisitor.
> > That approach may also handy in the
> >
> > >         def user = User.findByName(name)
> >
> > scenario since it would allow writing it as
> >
> > User.find { it.name == name }
> >
> > The SqlWhereVisitor actually works on the AST of the
> > Closure's expression and generates the SQL WHERE clause
> > from it.
> > I just learned about this possibility and I'm really
> > exited :-)
> >
> > cheers
> > Mittie
> >
>

[Dierk König]

Yes, it's very restrictive.
There may be possiblities for getting variables to work but they would
not be elegant, e.g.:

def name = "fred"
User.find {
    it.name = '$name'
}
// use the final String as input to a GStringTemplate
// or a GString...

> The other option is to used named queries like:
>
> def q = User.createQuery {
>        it.name = ":name"
> }
> q.params = [ "name" : "fred" ]
> def results = q.find()
>
> Which isn't quite as cool and flexible.. Any thoughts?

Yes, quite cool.
Have you read Andrew's article on Closure curry
http://www-128.ibm.com/developerworks/library/j-pg08235/
?

It may also have something in stock for the above and
maybe additionally be useful for 'injection' :-)
(but I haven't thought until the end...)

cheers
Mittie

[graemer]

On 02/11/05, Dierk Koenig <[hidden email]> wrote:

> Yes, it's very restrictive.
> There may be possiblities for getting variables to work but they would
> not be elegant, e.g.:
>
> def name = "fred"
> User.find {
>     it.name = '$name'
> }
> // use the final String as input to a GStringTemplate
> // or a GString...
>
> > The other option is to used named queries like:
> >
> > def q = User.createQuery {
> >        it.name = ":name"
> > }
> > q.params = [ "name" : "fred" ]
> > def results = q.find()
> >
> > Which isn't quite as cool and flexible.. Any thoughts?
>
> Yes, quite cool.
> Have you read Andrew's article on Closure curry
> http://www-128.ibm.com/developerworks/library/j-pg08235/
> ?
>
> It may also have something in stock for the above and
> maybe additionally be useful for 'injection' :-)
> (but I haven't thought until the end...)

Yes interesting article, but it requires you to have named arguments
to your closure:

def q = User.find { n, a ->
     it.name == n
     it.age > a
}
def name = "fred"
def results = q.curry(name, 45).call()

Interesting syntactically but not very clear in my opinion as to what
it is actually doing. A new user would look at that and go "eh?"

I'm still not convinced that it is worth the effort.

Graeme


>
> cheers
> Mittie
>

[Dierk König]

> I'm still not convinced that it is worth the effort.

Yes, I think we can close this 'track'.

Mittie

[Jochen Theodorou]

Graeme Rocher schrieb:

> Hmm although I was initially excited by this approach I think it does
> have limitation as I'm not sure how you would handle variable
> resolution. For example you can do:
>
> User.find {
>     it.name = "fred"
> }

some time ago I also thought about that to enable something like db4o's
native queries, but using builder. But it will not work unless we do
change the scoping rules a little like I suggested to John Wilson  in
the jsr list.

if so then:

User.find {
   name = "fred"
}

name would be resolved by the builder since there is no local varibale
name. The Builder gives an interceptable. On that interceptable the
method "equals" is used and would return again a Interceptable. Of
course that one is not used here.. but could.

So we have recorded that we want to have a column name, and it sould
have the value "fred". Next would be to build a query out of this. The
Closure would have to be run only one time and only to do an analyses
step.. but to be sure that there are not possible other changes it could
be runs multiple times of course.

I hope I can talk John into accepting my idea ;)

bye blackdrag

[graemer]

sounds like a good idea.. I like the syntax and the idea we just don't
have the capability to implement it unless you can persuade John ;-)

Graeme

On 02/11/05, Jochen Theodorou <[hidden email]> wrote:

> Graeme Rocher schrieb:
>
> > Hmm although I was initially excited by this approach I think it does
> > have limitation as I'm not sure how you would handle variable
> > resolution. For example you can do:
> >
> > User.find {
> >     it.name = "fred"
> > }
>
> some time ago I also thought about that to enable something like db4o's
> native queries, but using builder. But it will not work unless we do
> change the scoping rules a little like I suggested to John Wilson  in
> the jsr list.
>
> if so then:
>
> User.find {
>    name = "fred"
> }
>
> name would be resolved by the builder since there is no local varibale
> name. The Builder gives an interceptable. On that interceptable the
> method "equals" is used and would return again a Interceptable. Of
> course that one is not used here.. but could.
>
> So we have recorded that we want to have a column name, and it sould
> have the value "fred". Next would be to build a query out of this. The
> Closure would have to be run only one time and only to do an analyses
> step.. but to be sure that there are not possible other changes it could
> be runs multiple times of course.
>
> I hope I can talk John into accepting my idea ;)
>
> bye blackdrag
>

[Jochen Theodorou]

Graeme Rocher schrieb:

> sounds like a good idea.. I like the syntax and the idea we just don't
> have the capability to implement it unless you can persuade John ;-)

hehe, yes... maybe I should write another mail on the jsr list, the
thread seems to sleep a little atm

bye blackdrag