On Wednesday, June 26, 2019 at 2:43:44 PM UTC-4, Andrew Martin wrote:
>
> That's very interesting, Jonathan. Could you show me a quick example of
> that approach? I'm not sure I *need* to do that, but I think I would learn
> about SQLAlchemy from such an example and trying to understand it.
>
One large project has an 'internal api' that tries to centralize the
sqlalchemy interface.
Let's say we're searching for a "user". I would create a dict for the data
like this:
query_metadata = {'requester': 'site-admin', # admin interface, user
interface, user api, etc
'filters': {'Username=': 'foo', # just an internal
notation
},
'query_data': {}, # information related to what is
in the query as it is built
}
This payload is basically the same stuff you'd pass to as queryargs to one
of your functions above. We essentially pass it to our version of your
CRUD service which then acts on it to generate the query.
We don't implement this approach on every query - just on a handful of
queries that have intense logic with dozens of if/else statements and that
connect to multiple "filters". Stashing this in an easily accessible
manner has just been much easier than constantly trying to examine the
query to act on it.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/39a4a326-c384-4c91-909a-40d9c3acb323%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
