10 ms·
I'm loving all the momentum towards writing templated-sql, in fact, I wrote a library for this myself[1]. By leveraging jinja2/django-style template inheritanc
by dharbin 12y ago
I'm loving all the momentum towards writing templated-sql, in fact, I wrote a library for this myself[1].
By leveraging jinja2/django-style template inheritance, you can even bring some advantages of ORMs (composition, reuse, and extending) into the raw-sql world.
The OP also intimated that he's taking a templated approach:
"“In these cases, I've elected to write queries using a templating system and describe the tables using the ORM. I get the convenience of an application level description of the table with direct use of SQL. It's a lot less trouble than anything else I've used so far.”
[1] https://github.com/civitaslearning/swigql https://github.com/civitaslearning/swigql
- jdotjdot 12y agoIf you're at all interested in opening a kick starter for such a templating library for Django, I'd back it. I have attribute creep all the time and actually generally prefer raw SQL with the exception of its verbosity. The problem is, migrations are awful and SQL injection mistakes easy to come by. Would be great to have the best of both worlds in a SQL templating engine + sort-of ORM wrapper that auto-generates via SQL inspection
- kyllo 12y agoWithout the ORM, though, what would be the point of using Django? To me it seems like this would be a better fit for a more minimalist platform like Flask.
- deleted 12y ago[deleted]
- crazytony 12y agonot sure I follow? Most sql templates I have seen behave like Django's .raw() function (which inspects the resultset and auto binds to the object)