21–28 of 28 posts
Kudos for making the leap. Your pattern of re-interpreting __doc__ is kinda weird though. Why not just add a `return` statement?
Earlier quoted context omitted.
I honestly have no opinion in this discussion, but I will 100% upvote the first Fossil repository I've seen shared on here! How do you find developing on the Fossil platform?
It has a sane ui/syntax, all the additional infrastructure you might want is built in (webpage, wiki, forum, tickets) and is trivial to set up. It is nearly the perfect version control system. Especially for the small independent amateur developer.
Earlier quoted context omitted.
It has a sane ui/syntax, all the additional infrastructure you might want is built in (webpage, wiki, forum, tickets) and is trivial to set up. It is nearly the perfect version control system. Especially for the small independent amateur developer.
Awesome. Does it have any sort of CI/CD capabilities? And do you have any recommendations for learning resources for someone to get started?
As for CI there are pre-commit hooks I suspect could be used for that process. https://fossil-scm.org/home/help/hook and https://fossil-scm.org/home/doc/trunk/www/hooks.md
Kudos for making the leap. Your pattern of re-interpreting __doc__ is kinda weird though. Why not just add a `return` statement?
I guess it's more clear that it should be a to statically readable value? eg you shouldn't do things like use arguments to build the str
Our queries are typically large, not 3-5 liners.
(Filter view queries where you might add additional CTA’s to provide the necessary filter conditions, but aren’t desirable if particular filter parameter is nill, etc.)
Earlier quoted context omitted.
I guess it's more clear that it should be a to statically readable value? eg you shouldn't do things like use arguments to build the str
I would def use this if there was a return “select …” option. There are heaps of scenarios where sql is modified based on parameters. If no doc string just use the return value maybe? Our queries are typically large, not 3-5 liners. (Filter view queries where you might add additional CTA’s to provide the necessary filter conditions, but aren’t desirable if particular filter parameter is nill, etc.)
Here is my rather naive take on the same subject. But I had a very different motivation than the author. See I actually quite like SQL and enjoy programming in it, but what I don't like is mixing sql and python. So one night in a flash of inspiration or perhaps a fever dream I wrote this thing that lets you have stand alone parameterized sql queries and you call them like a python function or generator. It is one of…
The downside is that parameterized queries are a bit of a chore; for example, if a query should support an optional filter on user_id, you need to craft it like this:
WHERE ...
AND CASE
WHEN sqlc.narg('user_id') IS NOT NULL THEN sqlc.narg('user_id')
ELSE true
END
Earlier quoted context omitted.
I guess it's more clear that it should be a to statically readable value? eg you shouldn't do things like use arguments to build the str
I would def use this if there was a return “select …” option. There are heaps of scenarios where sql is modified based on parameters. If no doc string just use the return value maybe? Our queries are typically large, not 3-5 liners. (Filter view queries where you might add additional CTA’s to provide the necessary filter conditions, but aren’t desirable if particular filter parameter is nill, etc.)
Be very careful if you ever use bare string formatting to construct your queries.