Re: [sqlalchemy] checking in

[Mike Bayer]

discussion has mostly moved to github discussions:

https://github.com/sqlalchemy/sqlalchemy/discussions


at the same time there are a few emails per day here still, i just answered at 
least two or three since yesterday.


On Mon, Jun 14, 2021, at 5:25 PM, Rich Shepard wrote:
> I've not worked with SQLAlchemy for several years but now want to use it in
> a couple of applications. I've not seen messages on this maillist for a very
> long time so I tried subscribing and learned that I'm still subscribed.
> 
> Am I the only one on this list now?
> 
> If not I wonder why messages aren't arriving in my INBOX.
> 
> Rich
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/alpine.LNX.2.20.2106141423470.11603%40salmo.appl-ecosys.com.
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/ec72cac3-1cfd-4189-881f-4c6a08fb3ee9%40www.fastmail.com.

[sqlalchemy] checking in

[Rich Shepard]

I've not worked with SQLAlchemy for several years but now want to use it in
a couple of applications. I've not seen messages on this maillist for a very
long time so I tried subscribing and learned that I'm still subscribed.

Am I the only one on this list now?

If not I wonder why messages aren't arriving in my INBOX.

Rich

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/alpine.LNX.2.20.2106141423470.11603%40salmo.appl-ecosys.com.

Re: [sqlalchemy] Logging handler logic

[jca...@gmail.com]

Ok,
Thanks for the patience, I should have looked at this closer. This now has 
reliable behavior for my use case by not using the echo flag.

Thank you very much,
jlc

On Monday, June 14, 2021 at 5:33:41 AM UTC-6 Mike Bayer wrote:

> the echo flag doesn't support customization like this.   if you want to 
> use your own handlers then you should use traditional logging steps; 
> there's nothing the echo flag does that can't be accomplished using the 
> logging API directly.
>
>
>
> On Sun, Jun 13, 2021, at 10:24 PM, jca...@gmail.com wrote:
>
> Hi,
> Thank you for the response. The line I mentioned calls 
> _add_default_handler 
> 
>  if 
> it evaluates to true which attaches a stream handler set to sys.stdout.
>
> That's the crux of the concern, it checks its own logging namespace that 
> in most cases won't have a handler so it most likely (but not always) will 
> add a console stream handler all the time.
>
> I do want to use echo as I want the query and bind parameters on occasion, 
> I just don't think the stream handler is appropriate.
>
> The docs mentioned that you should adjust 'sqlalchemy.engine', however 
> that's not the namespace that gets a console stream handler, it is actually 
> 'sqlalchemy.engine.Engine'. After seeing this discrepancy, I was concerned 
> about what I may overlook and end up finding out the hard way.
>
> Thanks,
> jlc
>
> On Sunday, June 13, 2021 at 1:06:11 PM UTC-6 Mike Bayer wrote:
>
>
> the line you refer towards involves a flag called "echo", which is 
> described at 
> https://docs.sqlalchemy.org/en/14/core/engines.html#more-on-the-echo-flag 
> and is entirely optional.  if you don't use the echo flag, SQLAlchemy's 
> logging behavior is completely traditional, with the caveat that the 
> Engine, Connection and Pool objects will check the level of loggers before 
> opting to send out logging.info() and logging.debug() calls as there is 
> some additional formatting expense for some of these calls.
>
> I'm not familiar with what you mean by "IO emitted to the console streams 
> breaks calling code", SQLAlchemy doesn't emit any IO that it isn't 
> instructed to nor does it set up any handlers if you aren't using the 
> "echo" flag.
>
>
>
>
> On Sun, Jun 13, 2021, at 1:14 PM, jca...@gmail.com wrote:
>
> Hello everyone,
> After reviewing the handler logic, I am not clear that it implements 
> logging
> within the pattern guidelines defined by the base logging implementation.
>
> In log.py#L103 
> ,
>  
> the level and existence of at least one handler are checked.
>
> I only have a handler added to a root logger that I don't control, and we 
> rely
> on ancestral propagation.
>
> The concern I have is due to any IO emitted to the console streams breaks
> the calling code that I don't control. With this pattern, I have to 
> preemptively
> add null handlers to every logger, and if I miss one and it manifests in 
> production,
> I'll have a problem.
>
> Anyone have any thoughts around this?
>
> Thanks,
> jlc
>
>
>
> -- 
> 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+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/80cade67-c6ed-41a7-a1a2-ba1fdb36b8aen%40googlegroups.com
>  
> 
> .
>
>
>
> -- 
> 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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/58a12078-7a75-473a-9492-d9927580dd1en%40googlegroups.com
>  
> 
> .
>
>
>

-- 
SQLAlchemy - 
The Python SQL Toolkit and Object Relational Mapper

http://www.sqlalchemy.org/

To post example code, please provide an MCVE: Minimal, Complete, and 

Re: [sqlalchemy] Logging handler logic

[Mike Bayer]

the echo flag doesn't support customization like this.   if you want to use 
your own handlers then you should use traditional logging steps; there's 
nothing the echo flag does that can't be accomplished using the logging API 
directly.



On Sun, Jun 13, 2021, at 10:24 PM, jca...@gmail.com  
wrote:
> Hi,
> Thank you for the response. The line I mentioned calls _add_default_handler 
> 
>  if it evaluates to true which attaches a stream handler set to sys.stdout.
> 
> That's the crux of the concern, it checks its own logging namespace that in 
> most cases won't have a handler so it most likely (but not always) will add a 
> console stream handler all the time.
> 
> I do want to use echo as I want the query and bind parameters on occasion, I 
> just don't think the stream handler is appropriate.
> 
> The docs mentioned that you should adjust 'sqlalchemy.engine', however that's 
> not the namespace that gets a console stream handler, it is actually 
> 'sqlalchemy.engine.Engine'. After seeing this discrepancy, I was concerned 
> about what I may overlook and end up finding out the hard way.
> 
> Thanks,
> jlc
> 
> On Sunday, June 13, 2021 at 1:06:11 PM UTC-6 Mike Bayer wrote:
>> __
>> the line you refer towards involves a flag called "echo", which is described 
>> at https://docs.sqlalchemy.org/en/14/core/engines.html#more-on-the-echo-flag 
>> and is entirely optional.  if you don't use the echo flag, SQLAlchemy's 
>> logging behavior is completely traditional, with the caveat that the Engine, 
>> Connection and Pool objects will check the level of loggers before opting to 
>> send out logging.info() and logging.debug() calls as there is some 
>> additional formatting expense for some of these calls.
>> 
>> I'm not familiar with what you mean by "IO emitted to the console streams 
>> breaks calling code", SQLAlchemy doesn't emit any IO that it isn't 
>> instructed to nor does it set up any handlers if you aren't using the "echo" 
>> flag.
>> 
>> 
>> 
>> 
>> On Sun, Jun 13, 2021, at 1:14 PM, jca...@gmail.com wrote:
>>> Hello everyone,
>>> After reviewing the handler logic, I am not clear that it implements logging
>>> within the pattern guidelines defined by the base logging implementation.
>>> 
>>> In log.py#L103 
>>> ,
>>>  the level and existence of at least one handler are checked.
>>> 
>>> I only have a handler added to a root logger that I don't control, and we 
>>> rely
>>> on ancestral propagation.
>>> 
>>> The concern I have is due to any IO emitted to the console streams breaks
>>> the calling code that I don't control. With this pattern, I have to 
>>> preemptively
>>> add null handlers to every logger, and if I miss one and it manifests in 
>>> production,
>>> I'll have a problem.
>>> 
>>> Anyone have any thoughts around this?
>>> 
>>> Thanks,
>>> jlc
>>> 
>>> 
>>> 

>>> -- 
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sqlalchemy/80cade67-c6ed-41a7-a1a2-ba1fdb36b8aen%40googlegroups.com
>>>  
>>> .
>> 
> 

> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sqlalchemy/58a12078-7a75-473a-9492-d9927580dd1en%40googlegroups.com
>  
> .

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

Re: [sqlalchemy] issue with hybrid properties

[Julien Cigar]

On Tue, Jun 01, 2021 at 08:36:38AM -0400, Mike Bayer wrote:
> I can't make out your "ideal" SQL due to bad formatting however, if you want 
> the query to have an additional JOIN tacked onto it whenever you refer to 
> this hybrid property in the COLUMNS clause, you need to use query.join() 
> explicitly, either up front or by using something like a query builder 
> function or the do_orm_execute event to automatically alter the query.

Thank you Mike, I'm still wondering why with when I'm joining the 
row-limited relationship (through a window function) called 
"current_translation" in my case the generated FROM is wrong. It looks
like there is an issue when the aliased class is joined through
inheritance.

Attached my updated POC, the issue is in test_six and test_seven

(pytest -s poc.py)

you can clearly see that the FROM clause is wrong
(https://gist.github.com/silenius/3c090ee9470a4889e9812f7d8da64f56#file-gistfile1-txt-L28-L31),
although the .current_translation relationship is properly loaded
(https://gist.github.com/silenius/3c090ee9470a4889e9812f7d8da64f56#file-gistfile1-txt-L28-L31)

(and I'm sorry, but I'm still don't see how could I subselect from this
row-limited current_translation relationship in my hybrid property
expression ..)

Have a good day,
Julien

> 
> On Tue, Jun 1, 2021, at 6:58 AM, Julien Cigar wrote:
> > On Fri, May 28, 2021 at 10:53:26AM -0400, Mike Bayer wrote:
> > > the hybrid here is pulling in additional tables which are causing a 
> > > cartesian product since there is nothing joining the Document entity to 
> > > this other entity which seems to be DocumentTranslation.Run this in 
> > > 1.4 and you will see the warnings generated. an ORDER BY etc. has to 
> > > either produce a self-contained scalar expression, like a correlated 
> > > subquery, or you otherwise need to make sure the query has JOIN/WHERE to 
> > > link them together, such as:
> > > 
> > > q = (
> > > s.query(Document)
> > > .join(DocumentTranslation)
> > > .filter(Document.title.like("doc3%"))
> > > .order_by(Document.title)
> > > )
> > 
> > Thank you for your quick reply and help.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > It works with: .join(DocumentTranslation) or
> > 
> > 
> > 
> > .join(Document.translations). However it doesn't work with  
> > 
> > 
> > 
> > .join(Document.current_translation), the FROM clause is wrong (as you   
> > 
> > 
> > 
> > can see in my test_six()). This is because my Translation-like classes  
> > 
> > 
> > 
> > are polymorphic too I think.   
> > 
> > > 
> > > 
> > > seems like you'd be better off making sure Document.title returns a 
> > > correlated scalar subquery rather than what it does now which seems to be 
> > > :
> > > 
> > 
> > yes, this would be really the best, but I don't see how could I 
> > 
> > 
> > 
> > subselect from the .current_translation relationship (which is a
> > 
> > 
> > 
> > relationship on an orm.aliased filtered by a primaryjoin). Ideally I'd  
> > 
> >