Hi everybody,
I just about crack a gear every time I see raw SQL used in JS or some other
> language ecosystem. We have a space ship right here, right now. Why are
> people strapping cardboard to their arms? I've done it before myself many
> years ago and all I really learned was that it
On Thu, Aug 18, 2022 at 12:10 PM Ian Wilson wrote:
> I just about crack a gear every time I see raw SQL used in JS or some other
> language ecosystem. We have a space ship right here, right now. Why are
> people strapping cardboard to their arms? I've done it before myself many
> years ago
I guess SQLAlchemy is complicated but we are talking about a library for
interacting with SQL(!) (and sometimes even mysql!). The amount of effort
that has been put into the design, the documentation, the support, the
migration notes, deprecation warnings, BWC, etc. is inspiring. We are
spoiled
On Thu, Aug 18, 2022 at 5:03 AM Mikko Ohtamaa wrote:
> Nowadays I program SQLAlchemy by using StackOverflow. This is after 10 years
> of using SQLAlchemy. Makes the process more tolerable. However, the extra
> power you get from it in a big project is worth it. The project needs to be a
> big
Hi all,
A very interesting discussion thread!
>
> thats my own opinion , there is nothing wrong with SQLALCHEMY but I don't
> quite understand whats going on internally so I stopped.
>
This might be a bit off-topic, but this is the weak area of SqlAlchemy. It
is very brilliant engineering, but
I would like to thank you for taking the time to reply and simplify things.
yes I would like to go lower / close to metal because there is a lot of
postgresql API that I would like to access and experiment with.
I don't want to fight with any abstraction layer and development time is
really
I think it's worth noting that zope.sqlalchemy's session registration
supports a "readonly" initial state, similar to active and changed that
we've all harped on in the past. I'd probably just look into using that and
sticking with existing patterns. If you go all-in on readonly as a pattern
I
The SQLite database is pregenerated for a release and contains only
reference information. It's read only to the web application. So I'm
wondering if it's worth even hooking the session into the transaction
manager at all. I have a request subclass, and to open a session I use
a reified method:
transaction.doom() is a good way. Another is to register a commit_veto hook in
pyramid_tm. It is a hook that is invoked any time it would be about to commit,
giving you a chance to stop it. Advantage of the veto is that you can register
it from settings globally.
- Michael
> On Aug 16, 2022,
On Tuesday, August 16, 2022 at 11:45:24 AM UTC-4 Mike Orr wrote:
> It is rolling back in some of my testing when there's no
> insert/delete/update, but I want to make sure it always does, just in
> case something somehow modifies the database when we didn't intend to.
> It's not that big a deal
It is rolling back in some of my testing when there's no
insert/delete/update, but I want to make sure it always does, just in
case something somehow modifies the database when we didn't intend to.
It's not that big a deal but it's what I'd like. I'm not sure if
SQLAlchemy is issuing rollback if
On Mon, Aug 15, 2022 at 3:46 PM Jonathan Vanasco wrote:
>
>
> I second what Michael said. The sqlalchemy starter template is the right way
> to go.
>
> The major thing this template does, is provide you with the glue between a
> SQLAlchemy "Session" and the pyramid request. See :
>
sqlalchemy core is a better option than going straight to the driver imo.
And you can call postgresql functions from the session, however if you are
using pyramid transaction and zope.sqlalchemy you will want to get in the
habit of marking the transactions as changes were made for the functions
I second what Michael said. The sqlalchemy starter template is the right
way to go.
The major thing this template does, is provide you with the glue between a
SQLAlchemy "Session" and the pyramid request. See :
On Thu, Aug 11, 2022 at 9:54 AM pzzcc wrote:
> I want to avoid using SQLALCHEMY all together really to have a better
> understanding of how things work inside pyramid for integrating the tool with
> other tools already in place. so I think that is the correct route. once I
> get this to work ,
Thanks Laurent and Michael.
I want to avoid using *SQLALCHEMY* all together really to have a better
understanding of how things work inside pyramid for integrating the tool
with other tools already in place. so I think that is the correct route.
once I get this to work , I will have a deeper
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
Thanks Eldav ,
yes I would like to implement my own really to have a better understanding
of how things work.
thanks for the input and the resource.
On Thursday, August 11, 2022 at 7:25:27 PM UTC+3 Eldav wrote:
> sorry, database *abstraction* (stupid typo)
>
>
> Le jeudi 11 août 2022 à
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
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
20 matches
Mail list logo
