[sqlalchemy] Oracle connection problem

[jca...@gmail.com]

I am using sqlalchemy 1.4.22 and cx oracle 8.2.1 to connect to production 
and development environments that each host a similar copy of the same 
schema.

The connection string that I use is the same for each excluding the 
password:

oracle+cx_oracle://user:pass@MyTNS

Dev works without a problem, but prod throws an Oracle error:

ORA-12514: TNS:listener does not currently know of service requested in 
connect descriptor

We can connect using sqlplus with the same credentials and tns id, any idea 
why it may not work for one environment?

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/d7c9617c-b749-4149-9439-1212c72455dfn%40googlegroups.com.

[sqlalchemy] Common datetime call

[jca...@gmail.com]

Hi,
Does a means exist to generically call a local datetime func such that it 
renders as SYSDATE in Oracle and GETDATE() in SQL Server?

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/4f92c075-28b9-4c38-af10-5d21b8c83446n%40googlegroups.com.

[sqlalchemy] Proper date abstraction in case statement

[jca...@gmail.com]

Hi,
I have a case statement that should compare just the date for equality, 
however the code considers the time as well:

Model.dateCol == func.sysdate()

Another issue is this is a DATE field (therefore datetime) in an Oracle 
database in one environment and a DATE field (actual date) in an MSSQL 
database in another environment.

Would the correct way to achieve this comparison across both abstractions 
be:

cast(Model.dateCol, Date) == cast(func.sysdate(), Date)

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sqlalchemy/15a73018-1b07-453b-b545-d4aad6687df4n%40googlegroups.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 
> <https://github.com/sqlalchemy/sqlalchemy/blob/c2cad1f97c51c8a2a6ad5d371ece7bcd9c7ffcf9/lib/sqlalchemy/log.py#L34>
>  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 
> <https://github.com/sqlalchemy/sqlalchemy/blob/c2cad1f97c51c8a2a6ad5d371ece7bcd9c7ffcf9/lib/sqlalchemy/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
>  
> <https://groups.google.com/d/msgid/sqlalchemy/80cade67-c6ed-41a7-a1a2-ba1fdb36b8aen%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>
> -- 
> 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 

[sqlalchemy] Logging handler logic

[jca...@gmail.com]

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