On Tuesday, August 1, 2017 at 12:11:24 PM UTC+8, gneuner2 wrote:
> Hmm. A change to a query often also means a change to its arguments
> and/or its result columns, so I don't see that there is much utility
> in keeping the query strings separate from the program.
I'm not trying to "abstract" the query away from the code. I am trying to make
working with the SQL code easier. I want to update my workflow, so that, when I
see a line like:
(define query (sql-query "./some-file.sql"))
I can out the cursor in on the file name inside Emacs, type "C-c C-e RET", to
open the SQL file, type "C-c C-c" and get the query results in the SQL Repl
buffer. I can than edit the file, and verify the query, than, I can just save
it and the Racket program will pick it up.
> I certainly
> do test/debug my queries first using a SQL command line, but once
> they are working as I expect, I embed them into my application.
I did the same thing, but this method has several limitations which show up
once the SQL code starts to become more complex and you have to debug or update
them:
* For large queries, the string is quite large and hard to read. In particular
neither DrRacket nor racket-mode will highlight the SQL keywords inside strings
(and rightly so),
* If I want to debug, verify or check the execution plan of a query, I have to
extract it in a separate file and run it,
* Once I update the SQL query, I have to put it back into a string inside the
racket code, which is an error-prone task.
For an example of how this looks, have a look at
https://github.com/alex-hhh/ActivityLog2, search for virtual-query and
query-rows. In my opinion, it is no pretty and I'm open to suggestions on how
to improve this.
> I
> have a macro that allows me to write [nicely formatted] free-form
> SQL which gets converted into a query string suitable for use with
> the db library.
Could you share it?
> That said, if you really want to keep your SQL separate, I would not
> try to load query strings at the point of use. Instead I would load
> all the query strings at startup and store them in a hash table with
> appropriate identifiers. Then the query function could [minimally]
> be something like:
This, however will not address the workflow improvements that I'm trying to
make, as per my explanation above.
Best Regards,
Alex.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
