Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Eldav]

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 makes your arms really sore.
>

For Python, agreed, SQLAlchemy RuLeZ :) 

For JS, I have yet to find a convincing ORM. Prisma looked promising, that 
is, *until* I tried it. There are so many SQL constructs you just can't 
express with it.

Even with "Raw" SQL, expressing e.g. a "WHERE col IN " clause with a 
variable param seems to require black magick with Prisma.

So, *if* I have to write a backend function with SQL queries in JS, e.g. 
for Next.JS, I will use raw SQL. But I'll try to use a Python backend if 
that's feasible (some cloud-based start-ups are limited to JS-only 
environments...)

Laurent. 

-- 
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/3e60371a-79f0-463e-8213-196c3049b550n%40googlegroups.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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 and all I really learned was that it makes your arms really sore.

That was me before Pylons and WSGI. Web frameworks were like 1980s
microcomputers: every one was monolithic and non-interoperable. I
started using minimalist frameworks where I could read the entire docs
and code in half an hour. But they were so minimalist I had to write
my own database adapter, template integration, session manager, and
authentication/authorization. One thing that drew me to Pylons and
Pyramid was I could leverage libraries written by experts, yet they
were still modular and non-monolithic, so it's relatively easy to
substitute one of the libraries if you want to.

-- 
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/CAH9f%3DuqNJ5L%3DtACBQmhydKdyW%2BPYZHX0ctdFEgJ6Ky%2B%3Dgt_g%2BQ%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Ian Wilson]

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 in Python land and I don't want that to go unsaid.  The 2.0 changes
are going to make it even better.  The ORM loading features in it blow my
mind.  You can ORM and not ORM!   Reflection!  I love the library.  Thank
you zzzeek and friends!

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 makes your arms really sore.

Just my 2-cents.

- Ian

On Thu, Aug 18, 2022 at 6:16 AM Mike Orr  wrote:

> 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 though, and fit nicely into the web app/CRUD style scope.
> >
> > Which brings me to the offtopic questions: what are the best
> alternatives of SQLAlchemy in Python today - something that could be a bit
> easier to approach and might work better for smaller projects?
>
> Nothing does SQLAlchemy as well as SQLAlchemy. It's much better and
> more flexible than previous Python ORMs like SQLObject. However, it is
> complex, and the learning curve can be high. If you introspect a table
> or result object, or trace the code to see how a column type is
> implemented, etc, even a simple thing has several layers of calls and
> abstraction and you wonder whether it's overkill. So let me describe
> how to do low-level Postges things both with SQLAlchemy and without.
> I've used SQLAlchemy since ca. 2007 so I've gone through several
> versions and applied it to several websites. However, my experience is
> mostly in the 1.0 - 1.3 days, so I haven't migrated to the
> 2.0/1.4-future API yet. And I'm just writing from memory so the syntax
> may not be exact.
>
> First of all, you need an Engine and a Connection. You may want a
> Transaction and an (ORM) Session. Turn on logging so you can see the
> SQL statements executed: that's the key to seeing what it's doing with
> Postgres. The SQL may be more elaborate than you would write; e.g.,
> "SELECT `tablename`.fieldname" instead of "SELECT fieldname". Say you
> want to do everything with SQL strings:
>
> import logging
> import sqlalchemy
> logging.basicConfig(level=logging.INFO)
> logging.getLogger("sqlalchemy.engine").setLevel(logging.INFO)   #
> Enable SQL logging, or use engine 'echo' argument.
> t = sqlalchemy.text# Wrapper for SQL strings.
> dburl = "postgresql://USERNAME:PASSWORD@HOST/DBNAME"
> engine = sqlalchemy.create_engine(dburl)
> with engine.connect() as conn:
> # Different in 2.0: transactions, stricter text(), way of
> executing query and the result object.
> with conn.begin():# Transaction. Or use 'try' block for full
> commit/rollback control.
> sql = t "SQLECT id, priority, my_postgres_func() AS funk FROM
> tablename WHERE priority >= :pri")
> params = {"pri": 5}
> rslt = conn.execute(sql, params)
> rows = list(result)
> print(rows)
> print(tuple(rows[0])
> print(rows[0].funk)
> # Can also insert, delete, update, create tables, define
> Postgres functions, etc.
>
> Without SQLAlchemy, you can use 'psycopg2' directly. You'd connect,
> define a cursor, and do queries with the cursor, in the same spirit as
> the SQL string above.
>
> I normally define SQLAlchemy tables in any case, so that they're there
> for anything I might do in the future. You can define the columns
> explicitly, or use reflection to have SQLAlchemy figure it out from
> the existing database. I've also gone to using a Session in most
> cases, even if I'm only executing Core queries, again for flexibility.
> in 2.0 there's only one way to execute both Core and ORM queries
> anyway.
>
> --
> 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/CAH9f%3Dur%2Bxgfz5qg4oWPPfh6AE7YL5YnfuF75%2BVpy-X4kmKzohQ%40mail.gmail.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 

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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 though, and fit nicely into the web app/CRUD style scope.
>
> Which brings me to the offtopic questions: what are the best alternatives of 
> SQLAlchemy in Python today - something that could be a bit easier to approach 
> and might work better for smaller projects?

Nothing does SQLAlchemy as well as SQLAlchemy. It's much better and
more flexible than previous Python ORMs like SQLObject. However, it is
complex, and the learning curve can be high. If you introspect a table
or result object, or trace the code to see how a column type is
implemented, etc, even a simple thing has several layers of calls and
abstraction and you wonder whether it's overkill. So let me describe
how to do low-level Postges things both with SQLAlchemy and without.
I've used SQLAlchemy since ca. 2007 so I've gone through several
versions and applied it to several websites. However, my experience is
mostly in the 1.0 - 1.3 days, so I haven't migrated to the
2.0/1.4-future API yet. And I'm just writing from memory so the syntax
may not be exact.

First of all, you need an Engine and a Connection. You may want a
Transaction and an (ORM) Session. Turn on logging so you can see the
SQL statements executed: that's the key to seeing what it's doing with
Postgres. The SQL may be more elaborate than you would write; e.g.,
"SELECT `tablename`.fieldname" instead of "SELECT fieldname". Say you
want to do everything with SQL strings:

import logging
import sqlalchemy
logging.basicConfig(level=logging.INFO)
logging.getLogger("sqlalchemy.engine").setLevel(logging.INFO)   #
Enable SQL logging, or use engine 'echo' argument.
t = sqlalchemy.text# Wrapper for SQL strings.
dburl = "postgresql://USERNAME:PASSWORD@HOST/DBNAME"
engine = sqlalchemy.create_engine(dburl)
with engine.connect() as conn:
# Different in 2.0: transactions, stricter text(), way of
executing query and the result object.
with conn.begin():# Transaction. Or use 'try' block for full
commit/rollback control.
sql = t "SQLECT id, priority, my_postgres_func() AS funk FROM
tablename WHERE priority >= :pri")
params = {"pri": 5}
rslt = conn.execute(sql, params)
rows = list(result)
print(rows)
print(tuple(rows[0])
print(rows[0].funk)
# Can also insert, delete, update, create tables, define
Postgres functions, etc.

Without SQLAlchemy, you can use 'psycopg2' directly. You'd connect,
define a cursor, and do queries with the cursor, in the same spirit as
the SQL string above.

I normally define SQLAlchemy tables in any case, so that they're there
for anything I might do in the future. You can define the columns
explicitly, or use reflection to have SQLAlchemy figure it out from
the existing database. I've also gone to using a Session in most
cases, even if I'm only executing Core queries, again for flexibility.
in 2.0 there's only one way to execute both Core and ORM queries
anyway.

-- 
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/CAH9f%3Dur%2Bxgfz5qg4oWPPfh6AE7YL5YnfuF75%2BVpy-X4kmKzohQ%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mikko Ohtamaa]

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 it is a very complex beast. Due to the
legacy of Python documentation practices, its own documentation of
reference manual is not as good as some others (e.g. Django) making
SQLAlchemy harder to learn.

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 though, and fit nicely into the web app/CRUD style scope.

Which brings me to the offtopic questions: what are the best alternatives
of SQLAlchemy in Python today - something that could be a bit easier to
approach and might work better for smaller projects?

Myself, I am probably too old to start learning anything new, so I just use
SQLAlchemy and then drop to raw SQL strings when I need to deal with
something ORM cannot handle.

Br,
Mikko


>
> the more I look into postgres the more I want to make a use of it is
> features.
>
>
>
>
> On Wednesday, August 17, 2022 at 9:46:06 PM UTC+3 mmer...@gmail.com wrote:
>
>> 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 think it could be a lot simpler but hey, this lets you use the existing
>> pattern.
>>
>> On Wed, Aug 17, 2022 at 1:26 PM Jonathan Vanasco 
>> wrote:
>>
>>> If it's read-only, i would not have it join the transaction and just
>>> create the cleanup subscriber in the @reify .
>>>
>>> > # Because this was in the tutorial.
>>>
>>> I believe that is in there because of me. This pattern is used to
>>> provide access to the current request within SqlAlchemy objects and various
>>> @property or @reify decorated methods.  Without it, you must explicitly
>>> pass in a request (so no decorators) or use the `get_current_request`
>>> function which should generally be avoided.  There is a bit of discussion
>>> on it in the PR, and the cookiecutter template has many notes on it. See
>>> https://github.com/Pylons/pyramid-cookiecutter-starter/pull/111
>>>
>>> On Tuesday, August 16, 2022 at 5:50:02 PM UTC-4 Mike Orr wrote:
>>>
 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:

 @reify
 def sa_session(self):
 engine = self.registry.sa_engine # Attribute set during startup
 configuration.
 info = {"request": self} # Because this was in the tutorial.
 sess = sqlalchemy.orm.Session(engine, info=info)
 zope.sqlalchemy.register(sess) # Is this worth doing for a
 read-only database?
 return sess

 The transaction manager closes the session for me, so without it I
 guess I'd have to have a subscriber that rolls back and closes the
 request. I don't want to have to do it in every view because it's not
 view-specific logic.

 On Tue, Aug 16, 2022 at 9:19 AM 'Jonathan Vanasco' via pylons-discuss
  wrote:
 >
 > 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 but it's what I'd like. I'm not sure if
 > > SQLAlchemy is issuing rollback if there were no changes, or if it
 will
 > > always do so.
 >
 > That's from SQLAlchemy. It will rollback if there were no database
 writes. SQLAlchemy is unaware of raw sql being a write operation, so you
 need to use the `mark_changed` function from zope.sqlalchemy. This is a
 weird idiosyncrasy of SQLAlchemy and transaction - the transaction could be
 completely successful, but SQLAlchemy will rollback because there was no
 activity within it's scope.
 >
 > It sounds like you're trying to do the opposite of what the
 `transaction` package is designed to do.
 >
 > The way I normally deal with situations like that is to control if
 SQLAlchemy joins the transaction or not. In most projects, I only use the
 transaction on specific views that require this type of integration - such
 as anything that sends an email (pyramid_mailer integrates with
 pyramid_tm).
 >
 > It 

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[pzzcc]

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 not an issue since this tool is used only by me. so I am not under 
any pressure to iterate quickly or push out a new feature to meet any 
demand.

I remember a few years ago taking almost a day to modify a model to return 
json, it was so simple but it took me a day and I wasn't really sure of the 
internals so i was worried that It will take me months to understand 
SQLALCHEMY way of doing things , while what I was doing shouldn't take even 
half hour to accomplish. 

thats my own opinion , there is nothing wrong with SQLALCHEMY but I don't 
quite understand whats going on internally so I stopped.

the more I look into postgres the more I want to make a use of it is 
features. 




On Wednesday, August 17, 2022 at 9:46:06 PM UTC+3 mmer...@gmail.com wrote:

> 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 think it could be a lot simpler but hey, this lets you use the existing 
> pattern.
>
> On Wed, Aug 17, 2022 at 1:26 PM Jonathan Vanasco  
> wrote:
>
>> If it's read-only, i would not have it join the transaction and just 
>> create the cleanup subscriber in the @reify .  
>>
>> > # Because this was in the tutorial.
>>
>> I believe that is in there because of me. This pattern is used to provide 
>> access to the current request within SqlAlchemy objects and various 
>> @property or @reify decorated methods.  Without it, you must explicitly 
>> pass in a request (so no decorators) or use the `get_current_request` 
>> function which should generally be avoided.  There is a bit of discussion 
>> on it in the PR, and the cookiecutter template has many notes on it. See 
>> https://github.com/Pylons/pyramid-cookiecutter-starter/pull/111
>>
>> On Tuesday, August 16, 2022 at 5:50:02 PM UTC-4 Mike Orr wrote:
>>
>>> 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: 
>>>
>>> @reify 
>>> def sa_session(self): 
>>> engine = self.registry.sa_engine # Attribute set during startup 
>>> configuration. 
>>> info = {"request": self} # Because this was in the tutorial. 
>>> sess = sqlalchemy.orm.Session(engine, info=info) 
>>> zope.sqlalchemy.register(sess) # Is this worth doing for a 
>>> read-only database? 
>>> return sess 
>>>
>>> The transaction manager closes the session for me, so without it I 
>>> guess I'd have to have a subscriber that rolls back and closes the 
>>> request. I don't want to have to do it in every view because it's not 
>>> view-specific logic. 
>>>
>>> On Tue, Aug 16, 2022 at 9:19 AM 'Jonathan Vanasco' via pylons-discuss 
>>>  wrote: 
>>> > 
>>> > 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 but it's what I'd like. I'm not sure if 
>>> > > SQLAlchemy is issuing rollback if there were no changes, or if it 
>>> will 
>>> > > always do so. 
>>> > 
>>> > That's from SQLAlchemy. It will rollback if there were no database 
>>> writes. SQLAlchemy is unaware of raw sql being a write operation, so you 
>>> need to use the `mark_changed` function from zope.sqlalchemy. This is a 
>>> weird idiosyncrasy of SQLAlchemy and transaction - the transaction could be 
>>> completely successful, but SQLAlchemy will rollback because there was no 
>>> activity within it's scope. 
>>> > 
>>> > It sounds like you're trying to do the opposite of what the 
>>> `transaction` package is designed to do. 
>>> > 
>>> > The way I normally deal with situations like that is to control if 
>>> SQLAlchemy joins the transaction or not. In most projects, I only use the 
>>> transaction on specific views that require this type of integration - such 
>>> as anything that sends an email (pyramid_mailer integrates with 
>>> pyramid_tm). 
>>> > 
>>> > It also sounds like your concern is mostly in testing. The approach 
>>> I've started to standardize on is to have a database snapshot for tests and 
>>> just recreate the database from that on every run. If you just want to 
>>> completely disable database commits though, you could have your test 

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Michael Merickel]

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 think it could be a lot simpler but hey, this lets you use the existing
pattern.

On Wed, Aug 17, 2022 at 1:26 PM Jonathan Vanasco  wrote:

> If it's read-only, i would not have it join the transaction and just
> create the cleanup subscriber in the @reify .
>
> > # Because this was in the tutorial.
>
> I believe that is in there because of me. This pattern is used to provide
> access to the current request within SqlAlchemy objects and various
> @property or @reify decorated methods.  Without it, you must explicitly
> pass in a request (so no decorators) or use the `get_current_request`
> function which should generally be avoided.  There is a bit of discussion
> on it in the PR, and the cookiecutter template has many notes on it. See
> https://github.com/Pylons/pyramid-cookiecutter-starter/pull/111
>
> On Tuesday, August 16, 2022 at 5:50:02 PM UTC-4 Mike Orr wrote:
>
>> 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:
>>
>> @reify
>> def sa_session(self):
>> engine = self.registry.sa_engine # Attribute set during startup
>> configuration.
>> info = {"request": self} # Because this was in the tutorial.
>> sess = sqlalchemy.orm.Session(engine, info=info)
>> zope.sqlalchemy.register(sess) # Is this worth doing for a
>> read-only database?
>> return sess
>>
>> The transaction manager closes the session for me, so without it I
>> guess I'd have to have a subscriber that rolls back and closes the
>> request. I don't want to have to do it in every view because it's not
>> view-specific logic.
>>
>> On Tue, Aug 16, 2022 at 9:19 AM 'Jonathan Vanasco' via pylons-discuss
>>  wrote:
>> >
>> > 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 but it's what I'd like. I'm not sure if
>> > > SQLAlchemy is issuing rollback if there were no changes, or if it
>> will
>> > > always do so.
>> >
>> > That's from SQLAlchemy. It will rollback if there were no database
>> writes. SQLAlchemy is unaware of raw sql being a write operation, so you
>> need to use the `mark_changed` function from zope.sqlalchemy. This is a
>> weird idiosyncrasy of SQLAlchemy and transaction - the transaction could be
>> completely successful, but SQLAlchemy will rollback because there was no
>> activity within it's scope.
>> >
>> > It sounds like you're trying to do the opposite of what the
>> `transaction` package is designed to do.
>> >
>> > The way I normally deal with situations like that is to control if
>> SQLAlchemy joins the transaction or not. In most projects, I only use the
>> transaction on specific views that require this type of integration - such
>> as anything that sends an email (pyramid_mailer integrates with
>> pyramid_tm).
>> >
>> > It also sounds like your concern is mostly in testing. The approach
>> I've started to standardize on is to have a database snapshot for tests and
>> just recreate the database from that on every run. If you just want to
>> completely disable database commits though, you could have your test
>> harness set up a SQLAlchemy event listener for "commit", and then issue a
>> "rollback" within the event.
>> >
>> > --
>> > 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-discus...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pylons-discuss/771e180a-ca5b-4625-baf7-972d237ea45an%40googlegroups.com.
>>
>>
>>
>>
>> --
>> Mike Orr 
>>
> --
> 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/afd190a0-8b0e-412d-bd52-1ccdfe403994n%40googlegroups.com
> 
> .
>


-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this 

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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:

@reify
def sa_session(self):
engine = self.registry.sa_engine   # Attribute set during startup
configuration.
info = {"request": self}# Because this was in the tutorial.
sess = sqlalchemy.orm.Session(engine, info=info)
zope.sqlalchemy.register(sess)# Is this worth doing for a
read-only database?
return sess

The transaction manager closes the session for me, so without it I
guess I'd have to have a subscriber that rolls back and closes the
request. I don't want to have to do it in every view because it's not
view-specific logic.

On Tue, Aug 16, 2022 at 9:19 AM 'Jonathan Vanasco' via pylons-discuss
 wrote:
>
> 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 but it's what I'd like. I'm not sure if
> > SQLAlchemy is issuing rollback if there were no changes, or if it will
> > always do so.
>
> That's from SQLAlchemy. It will rollback if there were no database writes.  
> SQLAlchemy is unaware of raw sql being a write operation, so you need to use 
> the `mark_changed` function from zope.sqlalchemy.   This is a weird 
> idiosyncrasy of SQLAlchemy and transaction - the transaction could be 
> completely successful, but SQLAlchemy will rollback because there was no 
> activity within it's scope.
>
> It sounds like you're trying to do the opposite of what the `transaction` 
> package is designed to do.
>
> The way I normally deal with situations like that is to control if SQLAlchemy 
> joins the transaction or not.  In most projects, I only use the transaction 
> on specific views that require this type of integration - such as anything 
> that sends an email (pyramid_mailer integrates with pyramid_tm).
>
> It also sounds like your concern is mostly in testing.  The approach I've 
> started to standardize on is to have a database snapshot for tests and just 
> recreate the database from that on every run.  If you just want to completely 
> disable database commits though, you could have your test harness set up a 
> SQLAlchemy event listener for "commit", and then issue a "rollback" within 
> the event.
>
> --
> 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/771e180a-ca5b-4625-baf7-972d237ea45an%40googlegroups.com.



-- 
Mike Orr 

-- 
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/CAH9f%3Duq9HZVsyVJir4QzG0v8AXs-MURjxNAZ6uqH2LPkdiEW1A%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Michael Merickel]

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, at 10:42, Mike Orr  wrote:
> 
> 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 : 
>> https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py#L87-L127
>> 
>> If you run pyramid_tm (https://pypi.org/project/pyramid-tm/) you can then 
>> use zope.sqlalchemy (https://pypi.org/project/zope.sqlalchemy/) to bind the 
>> session to the transaction.
>> 
>> You don't need to use SQLAlchemy's ORM.  You can just use SQLAlchemy Core 
>> (https://docs.sqlalchemy.org/en/14/core/) to do everything.  You can also 
>> access the underlying psycopg2 connections through SQLAlchemy when you want.
> 
> Is there a way to make 'pyramid_tm' always roll back even on success?
> I looked in the code and there seemed to be no flag for that, and I'd
> either have to call 'transaction.doom()' in a subscriber or patch the
> obscure code several levels deep.
> 
> -- 
> 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/CAH9f%3DuqT58npmt6_sbfXJpVZ4hX7PNJdj1WqYXeXo7rJfhwPQQ%40mail.gmail.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/D770A14C-D365-42CC-9DCB-9D596E7B6B80%40gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

['Jonathan Vanasco' via pylons-discuss]

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 but it's what I'd like. I'm not sure if
> SQLAlchemy is issuing rollback if there were no changes, or if it will
> always do so.

That's from SQLAlchemy. It will rollback if there were no database writes.  
SQLAlchemy is unaware of raw sql being a write operation, so you need to 
use the `mark_changed` function from zope.sqlalchemy.   This is a weird 
idiosyncrasy of SQLAlchemy and transaction - the transaction could be 
completely successful, but SQLAlchemy will rollback because there was no 
activity within it's scope. 

It sounds like you're trying to do the opposite of what the `transaction` 
package is designed to do.

The way I normally deal with situations like that is to control if 
SQLAlchemy joins the transaction or not.  In most projects, I only use the 
transaction on specific views that require this type of integration - such 
as anything that sends an email (pyramid_mailer integrates with pyramid_tm).

It also sounds like your concern is mostly in testing.  The approach I've 
started to standardize on is to have a database snapshot for tests and just 
recreate the database from that on every run.  If you just want to 
completely disable database commits though, you could have your test 
harness set up a SQLAlchemy event listener for "commit", and then issue a 
"rollback" within the event.

-- 
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/771e180a-ca5b-4625-baf7-972d237ea45an%40googlegroups.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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 there were no changes, or if it will
always do so.

On Tue, Aug 16, 2022 at 8:42 AM Mike Orr  wrote:
>
> 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 : 
> > https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py#L87-L127
> >
> > If you run pyramid_tm (https://pypi.org/project/pyramid-tm/) you can then 
> > use zope.sqlalchemy (https://pypi.org/project/zope.sqlalchemy/) to bind the 
> > session to the transaction.
> >
> > You don't need to use SQLAlchemy's ORM.  You can just use SQLAlchemy Core 
> > (https://docs.sqlalchemy.org/en/14/core/) to do everything.  You can also 
> > access the underlying psycopg2 connections through SQLAlchemy when you want.
>
> Is there a way to make 'pyramid_tm' always roll back even on success?
> I looked in the code and there seemed to be no flag for that, and I'd
> either have to call 'transaction.doom()' in a subscriber or patch the
> obscure code several levels deep.



-- 
Mike Orr 

-- 
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/CAH9f%3Dup49Ag0ZZgTQ9j%3DRMAFqP-PCcF9AN8zSRiQqcefrwNVcw%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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 : 
> https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py#L87-L127
>
> If you run pyramid_tm (https://pypi.org/project/pyramid-tm/) you can then use 
> zope.sqlalchemy (https://pypi.org/project/zope.sqlalchemy/) to bind the 
> session to the transaction.
>
> You don't need to use SQLAlchemy's ORM.  You can just use SQLAlchemy Core 
> (https://docs.sqlalchemy.org/en/14/core/) to do everything.  You can also 
> access the underlying psycopg2 connections through SQLAlchemy when you want.

Is there a way to make 'pyramid_tm' always roll back even on success?
I looked in the code and there seemed to be no flag for that, and I'd
either have to call 'transaction.doom()' in a subscriber or patch the
obscure code several levels deep.

-- 
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/CAH9f%3DuqT58npmt6_sbfXJpVZ4hX7PNJdj1WqYXeXo7rJfhwPQQ%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Tom Willis]

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
that mutate data...


from zope.sqlalchemy import mark_changed
from sqlalchemy import func
result = session.execute(func.my_pg_func(*params)).scalar()
mark_changed(session)


On Mon, Aug 15, 2022 at 6: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 :
> https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py#L87-L127
>
> If you run pyramid_tm (https://pypi.org/project/pyramid-tm/) you can then
> use zope.sqlalchemy (https://pypi.org/project/zope.sqlalchemy/) to bind
> the session to the transaction.
>
> You don't need to use SQLAlchemy's ORM.  You can just use SQLAlchemy Core (
> https://docs.sqlalchemy.org/en/14/core/) to do everything.  You can also
> access the underlying psycopg2 connections through SQLAlchemy when you want.
>
> There is not a lot of code to rewrite if you want to eliminate SqlAlchemy
> and start from scratch - probably only 100-400 lines worth, and as Arndt
> Droullier said it is pretty straightforward -- but you're going to have to
> maintain that, and the entrypoints are somewhat rough.  Even in that
> situation, starting with the sqlalchemy cookiecutter is your best option as
> it will give you a better idea as to where your code needs to go.
>
>
> On Thursday, August 11, 2022 at 12:38:36 PM UTC-4 mmer...@gmail.com wrote:
>
>> 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.
>>
>>
>
> --
> 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/fd53e026-af8b-45ed-b4fe-df073e50f0e7n%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/CANVFhUqwxWd-fOZ-qy2phhDkNkjhA3OscXXwh9Vdis%3DnH1B-tw%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Jonathan Vanasco]

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 : 
https://github.com/Pylons/pyramid-cookiecutter-starter/blob/latest/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/sqlalchemy_models/__init__.py#L87-L127

If you run pyramid_tm (https://pypi.org/project/pyramid-tm/) you can then 
use zope.sqlalchemy (https://pypi.org/project/zope.sqlalchemy/) to bind the 
session to the transaction.

You don't need to use SQLAlchemy's ORM.  You can just use SQLAlchemy Core 
(https://docs.sqlalchemy.org/en/14/core/) to do everything.  You can also 
access the underlying psycopg2 connections through SQLAlchemy when you want.

There is not a lot of code to rewrite if you want to eliminate SqlAlchemy 
and start from scratch - probably only 100-400 lines worth, and as Arndt 
Droullier said it is pretty straightforward -- but you're going to have to 
maintain that, and the entrypoints are somewhat rough.  Even in that 
situation, starting with the sqlalchemy cookiecutter is your best option as 
it will give you a better idea as to where your code needs to go.


On Thursday, August 11, 2022 at 12:38:36 PM UTC-4 mmer...@gmail.com wrote:

> 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.
>
>  

-- 
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/fd53e026-af8b-45ed-b4fe-df073e50f0e7n%40googlegroups.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Mike Orr]

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 , I will have a deeper understanding of pyramid in general 
> which will help integrating that tool into the system we already have in place

If you get out of SQLAlchemy and the transaction manager, then you're
getting out of Pyramid's database toolchains. I.e., you're
DEintegrating, not integrating. What you'll learn is the low-level
database API (psycopg2, based on Python's DBAPI interface). That's
worth learning about if you like low-level close-to-the-metal tools.
It can do simple tasks fine, but large abstract concepts or large
development teams may do better with something high-level like
SQLAlchemy.

SQLAlchemy's creator, Michael Beyer, has given talks at several
Pycons, and is friends with the people who created Pylons and Pyramid.
He's a super-expert on SQL. So there's also value in benefiting from
his expertise when you use SQLAlchemy, and when you look at how
flexible SQLAlchemy can be. He also wrote the Mako template engine.

-- 
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/CAH9f%3DupCUZ2DiVOb%3D7NSgJDbe1JLwOYFOkcjPMM8htsmL-Nduw%40mail.gmail.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[pzzcc]

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 understanding of pyramid in 
general which will help integrating that tool into the system we already 
have in place .

thanks a lot for the input, I appreciate everyone's time. 





On Thursday, August 11, 2022 at 7:38:36 PM UTC+3 mmer...@gmail.com wrote:

> 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  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-discus...@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/17e89621-1f04-461f-b306-8ddd5f7513bfn%40googlegroups.com.

Re: [pylons-discuss] Re: using pyramid without an ORM ?

[Michael Merickel]

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  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.