Hi all,
Could anyone with CVS write acces commit Glynn's latest patch for the sql
parser? Paul? Glynn? I attach it here so you don't have to seek through past
emails.
Even if it were not perfect, it's still a right step in debugging the current
broken parser, isn't it?
-- Daniel Calvelo Aros
whereexpressions.patch (3.4 KB)
Daniel Calvelo Aros wrote:
Could anyone with CVS write acces commit Glynn's latest patch for the sql
parser? Paul? Glynn? I attach it here so you don't have to seek through past
emails.
Done.
Even if it were not perfect, it's still a right step in debugging the current
broken parser, isn't it?
What's still wrong with the parsing?
The issue of only being able to use constants on the RHS of SET
clauses is a limitation of the DBF driver.
--
Glynn Clements <glynn@gclements.plus.com>
From: Glynn Clements <glynn@gclements.plus.com>
Sent: Fri, 1 Jul 2005 18:54:44 +0100
Daniel Calvelo Aros wrote:
> Could anyone with CVS write acces commit Glynn's latest patch for the sql
> parser? Paul? Glynn? I attach it here so you don't have to seek through past
> emails.Done.
Thank you!
> Even if it were not perfect, it's still a right step in debugging the current
> broken parser, isn't it?What's still wrong with the parsing?
AFAICT nothing, it was just a supporting comment, given Paul's asking for more
thorough testing. Sorry if I was confusing.
The issue of only being able to use constants on the RHS of SET
clauses is a limitation of the DBF driver.
Have you got ideas on how to fix this? I'm willing to dig into it.
For v.db.update use, I thought about bypassing the limitation by calculating
output values from the expression and then do a (large) number of SETs, but
that is very awkward.
Another possibility is to dump the dbf into sqlite, perform advanced sql stuff
there and dump back to dbf. Are there plans to leverage sqlite for the DBMI
infrastructure?
Daniel.
On Fri, 1 Jul 2005, Daniel Calvelo Aros wrote:
From: Glynn Clements <glynn@gclements.plus.com>
What's still wrong with the parsing?
AFAICT nothing, it was just a supporting comment, given Paul's asking for more
thorough testing. Sorry if I was confusing.
I'm sure it's fine now. The Solaris machine I had been testing it on has been wiped and re-installed with something else now so can't confirm that but don't anticipate a problem.
Paul
On Fri, July 1, 2005 20:00, Daniel Calvelo Aros said:
For v.db.update use, I thought about bypassing the limitation by calculating
output values from the expression and then do a (large) number of SETs, but
that is very awkward.
I thought about this solution as well, but I think it would be more helpful to
fix the driver or go the sqlite route...
Another possibility is to dump the dbf into sqlite, perform advanced sql stuff
there and dump back to dbf. Are there plans to leverage sqlite for the DBMI
infrastructure?
Markus has suggested this repeatedly
(http://grass.itc.it/pipermail/grass5/2005-February/017368.html,
http://www.intevation.de/rt/webrt?serial_num=815&display=History,
http://grass.itc.it/pipermail/grass5/2005-May/018415.html), but AFAIK no one
has undertaken any concrete steps. I would support the motion, though...
Moritz
Glynn Clements wrote:
Daniel Calvelo Aros wrote:
Could anyone with CVS write acces commit Glynn's latest patch for the sql
parser? Paul? Glynn? I attach it here so you don't have to seek through past
emails.Done.
The change to the Makefile (see below) seems to stop y.tab.h being generated (on Cygwin anyway, and compilation then fails in that directory). No idea why.
RCS file: /grassrepository/grass51/lib/db/sqlp/Makefile,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- Makefile 19 May 2004 14:02:05 -0000 1.5
+++ Makefile 1 Jul 2005 17:51:34 -0000 1.6
@@ -16,10 +16,10 @@
default: lib
$(MKDIR) $(GISBASE)/docs/html
$(INSTALL) -m 644 description.html $(GISBASE)/docs/html/sql.html
-
-y.tab.c: yac.y
+
+y.tab.c y.tab.h: yac.y
$(YACC) -d -v yac.y
-lex.yy.c: lex.l y.tab.c
+lex.yy.c: lex.l
$(LEX) lex.l
Paul Kelly wrote:
> > Could anyone with CVS write acces commit Glynn's latest patch for the sql
> > parser? Paul? Glynn? I attach it here so you don't have to seek through past
> > emails.
>
>
> Done.The change to the Makefile (see below) seems to stop y.tab.h being
generated (on Cygwin anyway, and compilation then fails in that
directory). No idea why.
-
-y.tab.c: yac.y
+
+y.tab.c y.tab.h: yac.y
$(YACC) -d -v yac.y-lex.yy.c: lex.l y.tab.c
+lex.yy.c: lex.l
$(LEX) lex.l
According to the Makefile, nothing depends upon y.tab.h, so it won't
get rebuilt if it is missing. It will get rebuilt along with y.tab.c,
but that won't occur until y.tab.o is required, while y.tab.h is
required by lex.yy.o. Because the dependencies are generated
automatically using $(wildcard ...), which returns results in
alphabetical order, lex.yy.o will come before y.tab.o.
The old rule for lex.yy.c would force y.tab.c to be regenerated from
yac.y whenever lex.yy.c was required (even though lex.yy.c doesn't
actually *depend* upon y.tab.c). A side effect of regenerating y.tab.c
is to regenerate y.tab.h. As lex.yy.o requires both lex.yy.c and
y.tab.h, this would do the right thing, although more by luck than
judgement.
The missing rule is probably:
$(OBJDIR)/lex.yy.o: lex.yy.c y.tab.h
(with no action; the default $(OBJDIR)/%.o rule in Rules.make should
provide the correct action).
I'll commit that once I've had a chance to test it.
--
Glynn Clements <glynn@gclements.plus.com>