[sqlalchemy] orm and raw sql inserts customization

I'm struggling trying to "INSERT IGNORE" into mysql database. I am using ORM. All info I've found is about prefixing queries, found nothing about possibility of prefixing inserts... any help? -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. T

Re: [sqlalchemy] Session autoflush when using history_meta (examples/versioned_history)

Thank you Mike, I will strongly consider creating a PR for an alternative solution. I would need to dig into the library to learn the basics of sqlalchemy architecture though. So far, I have only used 0.9.x and few of the recipes. Recommendations for "reading/learning" material I should get on

[sqlalchemy] iPtyhon is swallowing exceptions raised within an ORM event listener

Hey all, I've set up a couple of ORM event listeners using the `event.listen` api. When executing in the context of an iPython shell, any exceptions that are raised within these listeners are completely lost... as in there's no traceback whatsoever. Does anyone have any experience with this?

Re: [sqlalchemy] Session autoflush when using history_meta (examples/versioned_history)

On 09/02/2016 01:42 PM, HP3 wrote: Hello all: We are using examples/versioned_history (i.e. history_meta.py) https://github.com/zzzeek/sqlalchemy/blob/master/examples/versioned_history/history_meta.py We noticed the following behavior: Within the same transaction (i.e. pyramid_tm), whenever

[sqlalchemy] Session autoflush when using history_meta (examples/versioned_history)

Hello all: We are using examples/versioned_history (i.e. history_meta.py) https://github.com/zzzeek/sqlalchemy/blob/master/examples/versioned_history/history_meta.py We noticed the following behavior: Within the same transaction (i.e. pyramid_tm), whenever a Versioned object changes and its fo

Re: [sqlalchemy] examples/versioned_history test_versioning.py doubts about TestVersioning.test_relationship

Thank you Simon I hadn't realized that sessions are created with autoflush=True So would each change make to any object in session followed by a query trigger a version increase? I am about to test this scenario: assert sc.version == 1 sc.name = "a" query... sc.name = "b" query.. assert sc.ve

Re: [sqlalchemy] examples/versioned_history test_versioning.py doubts about TestVersioning.test_relationship

By default, the session is flushed before any query, so that the query results are consistent with changes you may have made in-memory: http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#flushing Hope that helps, Simon On Fri, Sep 2, 2016 at 5:12 PM, HP3 wrote: > Hello all: > > > We

[sqlalchemy] examples/versioned_history test_versioning.py doubts about TestVersioning.test_relationship

Hello all: We are running into an issue while using history_meta.py (examples/versioned_history). I am running test_versioning.py (via sqla_nose) but I am confused about test_relationship unit-test. It asserts sc.version == 3 without an intermediate sess.commit() ... why would the vers

Re: [sqlalchemy] Inherited abstract model with relationship causing "Cannot compile Column object until its 'name' is assigned."

OK I'm going to fix that for 1.1, this is https://bitbucket.org/zzzeek/sqlalchemy/issues/3789/allow-strsqlcompiler-to-generate-columns-w. On 09/02/2016 10:57 AM, TomS. wrote: On 09/02/2016 04:37 PM, Mike Bayer wrote: On 09/02/2016 10:25 AM, TomS. wrote: On 08/30/2016 08:25 PM, Mike B

Re: [sqlalchemy] Re: Unnecessary SELECTS for association object instances via composite key?

thanks for this test. this is issue https://bitbucket.org/zzzeek/sqlalchemy/issues/3788/simple-many-to-one-comparison-is-sensitive and the fix is going through targeted at 1.1 for now. On 09/02/2016 12:39 AM, YKdvd wrote: I think I may have found the issue. If I modify your example so that

Re: [sqlalchemy] Inherited abstract model with relationship causing "Cannot compile Column object until its 'name' is assigned."

On 09/02/2016 04:37 PM, Mike Bayer wrote: On 09/02/2016 10:25 AM, TomS. wrote: On 08/30/2016 08:25 PM, Mike Bayer wrote: On 08/30/2016 01:54 PM, TomS. wrote: Hi, I would like to create an abstract model which should be inherited. Unfortunately, I am not allowed to used Foreign Keys, this

Re: [sqlalchemy] Inherited abstract model with relationship causing "Cannot compile Column object until its 'name' is assigned."

On 09/02/2016 10:25 AM, TomS. wrote: On 08/30/2016 08:25 PM, Mike Bayer wrote: On 08/30/2016 01:54 PM, TomS. wrote: Hi, I would like to create an abstract model which should be inherited. Unfortunately, I am not allowed to used Foreign Keys, this is the reason why I introduced work around

Re: [sqlalchemy] How to import from and to postgres/spatialite column real/float type

On 09/02/2016 03:08 AM, pyArchInit ArcheoImagineers wrote: > On spatialite the column type Float remains Float, but in Postgres the > Column becomes Real. Postgresql doesn't use the word "Float" to represent the type. It accepts the word "float" to create the type, but d

Re: [sqlalchemy] Inherited abstract model with relationship causing "Cannot compile Column object until its 'name' is assigned."

On 08/30/2016 08:25 PM, Mike Bayer wrote: On 08/30/2016 01:54 PM, TomS. wrote: Hi, I would like to create an abstract model which should be inherited. Unfortunately, I am not allowed to used Foreign Keys, this is the reason why I introduced work around via relationship. Here is the whole cod

Re: [sqlalchemy] How to import from and to postgres/spatialite column real/float type

> > On spatialite the column type Float remains Float, but in Postgres the > > Column becomes Real. > > > Postgresql doesn't use the word "Float" to represent the type. It > accepts the word "float" to create the type, but depending on precision > will resolve it to REAL or DOUBLE PRECISION.