Re: [sqlalchemy] Declaring column NOT NULL only for specific dialect (Oracle)?

2016-04-22 Thread Mike Bayer



On 04/22/2016 11:51 AM, Piotr Dobrogost wrote:

 >On Friday, April 22, 2016 at 5:02:17 PM UTC+2, Mike Bayer wrote:
 >
 >For this one, assuming you're using metadata.create_all() and not an
 >alembic migration, the CreateColumn DDL construct gives you a hook for
 >this kind of thing:

Thanks for info. Yes, I'm using create_all() but eventually I'll have to
start using alembic. Are there any problems with using alembic in the
future while creating initial db schema with create_all()?


In Alembic I don't think directives like "add_column()" are currently 
taking advantage of the CreateColumn construct.   create_table() should 
be however.




 >Column('some_col', nullable=False, info={"oracle_not_null": False})
 >
 >then in your @compiles recipe look for column.info
['oracle_not_null']
 >while at the same time looking at compiler.dialect.name
 == 'oracle'.

I get it. However as we want this for every autoincrement column I guess
we can check for already provided "autoincrement" flag and avoid passing
column.info altogether. Nice.

It seems like this could be used to render IDENTITY keyword for
autoincrement columns for Oracle 12c which I asked about recently in my
post titled "Support for Oracle 12c auto increment (IDENTITY) columns?"
(https://groups.google.com/forum/#!topic/sqlalchemy/Jg_kV6VF0_E).


yes, you can write whatever rendering you want in there.





Regards,
Piotr Dobrogost

--
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 post to this group, send email to sqlalchemy@googlegroups.com
.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


[sqlalchemy] Bug in BufferedColumnResultProxy class?

2016-04-22 Thread Piotr Dobrogost
It seems BufferedColumnResultProxy class (used only in Oracle dialect) has 
a bug.

_init_metadata() method defined at 
https://github.com/zzzeek/sqlalchemy/blob/rel_1_0_12/lib/sqlalchemy/engine/result.py#L1238
is being called even for already cached data (that's probably bug) and 
because this method clears a list of processors (metadata._processors = 
[None for _ in range(len(metadata.keys))]) the list of original processors 
(metadata._orig_processors) gets cleared the second time _init_metadata() 
method is called. The end result is that column's value is not being 
processed to proper Python type from the db original type and one gets 
errors like:

File 
"/home/piotr/.virtualenvs/kotti/lib/python2.7/site-packages/sqlalchemy/ext/mutable.py",
 
line 403, in coerce
raise ValueError(msg % (key, type(value)))
ValueError: Attribute '_acl' does not accept objects of type 

Whole traceback is available at http://pastebin.com/Ssui33XC

Guarding method's body after line L1240 with "if not hasattr(metadata, 
'_orig_processors'):" solves the problem but it's neither pretty nor it's 
the right solution. The right solution is probably to not call 
_init_metadata() method on cached data at all.

I'd appreciate if someone with good understanding of SA internals could 
take a look and confirm (better yet fix) this bug. I have to admit it took 
a top notch developer a couple of hours of debugging to go through much of 
SA code and establish the root cause of this problem.

I'm going to raise issue on tracker as soon as someone confirms this bug.

Best regards,
Piotr Dobrogost

-- 
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 post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


[sqlalchemy] Declaring column NOT NULL only for specific dialect (Oracle)?

2016-04-22 Thread Piotr Dobrogost

As Oracle does not support inserting empty string into NOT NULL column I 
would like to declare specific column as nullable only for Oracle.
How can I do this?

Regards,
Piotr Dobrogost

-- 
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 post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


[sqlalchemy] Re: plain text versus html mail

2016-04-22 Thread Chris Withers

On 22/04/2016 03:04, Ben Finney wrote:

Chris Withers  writes:


[no text body]


When posting to mailing lists, please be sure to have a plain text body
with the full information. Not everyone wants to enable HTML in email
just to read a software announcement :-)


I used to have this view, but I'm afraid the world has moved on. I think 
plain text messages are more likely to be treated as spam than HTML now, 
and I appreciate the ability to format mails, even if Thunderbird does 
then butcher that formatting during delivery.


I dunno, what's the consensus?

Chris

--
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 post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.