As Laurent said, if I were starting from scratch a new project I would personally use the pyramid-cookiecutter-starter sqlalchemy and then rip out what I didn’t need but only one part of that cookie cutter is the ORM. It has several other features that you need to solve one way or another so you’d at least want to know what you’re getting rid of. It is modular and you can pick the layers you want.
- connection pooling - transaction binding to request lifecycle to rollback or commit at optimal times - tables mappings to assist in converting database types into python - ORM objects a more comprehensive query language on top of those tables - alembic for autogenerating migrations from those models and helping with database versioning If you go with only the first couple layers you can rip the rest out and just use dbsession.execute() like you would in psycopg2 and just set the zope.sqlalchemy initial_state=‘changed’. You can accomplish everything done here without sqlalchemy as well - but you will still want to understand the layers and reasons for the fundamental patterns to hook into pyramid. The sqlalchemy part of the config can be replaced almost directly with psycopg2 versions of everything and it just ends up being more specific to that application. You will need to use the cookbook entries to manage your connections/transactions as I don’t think there’s a pyramid_tm binding for psycopg2 directly - although it’s likely easy to write that DataManager. - Michael > On Aug 11, 2022, at 09:25, Eldav <ldave...@gmail.com> wrote: > > > sorry, database *abstraction* (stupid typo) > > >> Le jeudi 11 août 2022 à 18:22:07 UTC+2, Eldav a écrit : >> Hello, >> >> afaik, nothing forces you to use SQLAlchemy with Pyramid (after all, you >> could decide to use a non-relational database such as the ZODB or MongoDB). >> >> If you are sure that you won't need database attraction later, you can talk >> to psycopg2/3 directly. By doing so, you will also lose the possibility to >> automatically synchronise SQL transactions with Pyramid. It may or may not >> be ok for you, depending on your problem, but it's certainly possible to >> implement the required mechanism if required. >> >> On the other hand, you might decide to run your raw SQL queries via >> SQLAlchemy, without using the ORM parts. This would give you the transaction >> synchronisation, provided you remember to mark your DB session as changed >> (look for "mark_changed" in >> https://pypi.org/project/zope.sqlalchemy/#full-example) after an >> insert/update/delete query. >> >> Hope this helps, >> >> Laurent. >> >>> Le jeudi 11 août 2022 à 17:53:31 UTC+2, grc...@gmail.com a écrit : >>> Hello , >>> >>> I am building an application ( more of a tool really ) that have a web >>> interface , and I am trying to avoid using ORM all together. plus I want to >>> try postgresql features and experiment more with them. >>> >>> I don't want things to be overly complicated on the web interface so I put >>> lots of logic , something that I know will not change any time soon , into >>> PostgreSQL directly using functions etc. >>> >>> can you please point me to the right direction of using pyramid without it >>> ? what might be the pitfalls of not using an ORM with pyramid ? >>> >>> >>> >>> Thanks ! > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-discuss+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/d1ab4b3d-48be-48d4-aafb-1cc9cc2ef1b5n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/F3EB17C1-D866-48C9-93C2-56AEA94AA330%40gmail.com.
