Anybody?
On Jun 4, 1:13 am, AF allen.fow...@yahoo.com wrote:
Hello,
I'm using sqlite and convert_unicode = True on the engine.
How can I force coerce string based object attributes in to unicode?
(I had thought convert_unicode = True would do this)
Here is what I am seeing...
Setup
The engine's conversion to unicode doesn't happen when you assign the
property, it happens when the underlying database operation is
committed, and arrives in the python object's property only after
roundtripping through the database.
In [50]: m1.body = 'new - NOT unicode'
In [51]: m1.body
chingi wrote:
Hello,
In my application I have AJAX function which sends around 20
requests every 5 seconds to Server to update my web page.
But few requests fail to get values because of
invalidRequestError : The transaction is inactive due to a rollback
in a
David Gardner wrote:
OK I think that would work for me.
I have another question in regards to joined table inheritance and
performance.
At work we are planning to restructure our database schema, and what we
are considering doing is
creating an adjacency list, of objects using joined
this is likely a bug. try out the patch below (against the latest 0.5
release):
Index: lib/sqlalchemy/orm/state.py
===
--- lib/sqlalchemy/orm/state.py (revision 6049)
+++ lib/sqlalchemy/orm/state.py (working copy)
@@ -111,8 +111,8
Hi Michael,
On 12-06-2009 16:22, Michael Bayer wrote:
this is likely a bug. try out the patch below (against the latest 0.5
release):
After applying the patch it works perfectly. Thanks a lot!
Regards,
Roel
Index: lib/sqlalchemy/orm/state.py
Ok we'll have to ensure this doesn't break anything, that line doesn't
seem to be covered in the current unit tests
Roel van Os wrote:
Hi Michael,
On 12-06-2009 16:22, Michael Bayer wrote:
this is likely a bug. try out the patch below (against the latest 0.5
release):
After applying the
On Jun 12, 6:00 am, Gunnlaugur Briem gunnlau...@gmail.com wrote:
The engine's conversion to unicode doesn't happen when you assign the
property, it happens when the underlying database operation is
committed, and arrives in the python object's property only after
roundtripping through the
allen.fowler wrote:
On Jun 12, 6:00 am, Gunnlaugur Briem gunnlau...@gmail.com wrote:
The engine's conversion to unicode doesn't happen when you assign the
property, it happens when the underlying database operation is
committed, and arrives in the python object's property only after
Hi,
I noticed that when I use the @synonym_for decorator, my function docstring
get lost.
I got lost in SA code around the attributes.register_descriptor function,
which is one of the steps I guess the doc is not copied (along with the
decorator function itself), and cannot propose a patch.
I
Hello all.
I think that logging in SQLAlchemy should be a bit more straightforward.
First issue is _should_log_* properties. What for are they exist?
Standard lib's logging module allows to fine-tune levels per-logger or
per-handler. But with those strange props such simple code works not
as it
I think that patch which you would like to provide could add
functools.wraps decorator to the decorator defined in synonym_for().
See http://docs.python.org/library/functools.html#functools.wraps
--
Anton Gritsay
http://angri.ru
On 12 июн, 22:20, Christophe de VIENNE cdevie...@gmail.com wrote:
General wrote:
First issue is _should_log_* properties. What for are they exist?
Standard lib's logging module allows to fine-tune levels per-logger or
per-handler. But with those strange props such simple code works not
as it should:
engine_logger =
try this patch:
Index: lib/sqlalchemy/ext/declarative.py
===
--- lib/sqlalchemy/ext/declarative.py (revision 6051)
+++ lib/sqlalchemy/ext/declarative.py (working copy)
@@ -639,8 +639,9 @@
prop = synonym('col',
Hello:
When I use the foreign_keys argument to the relation function in the
mapper of SA, I get the following error:
ArgumentError: Could not determine relation direction for primaryjoin
condition 'drm_owners.owner_id = drm_contract_royalties.contract_id',
on relation Royalty.owner. Specify the
The error is complaining about the backref (on relation
Royalty.owner), so it makes sense that it would go away if you remove
the backref.
The error says that you need to specify foreign_keys for the backref,
so you should try that. i.e, change
backref='owner'
to
backref=backref('owner',
the foreign keys argument as yet is not propagated to the backref (the
primaryjoin is), I should look into fixing that, but for now use
backref=backref('owner', primaryjoin=pj, foreign_keys=[the foreign keys]).
Affect wrote:
Hello:
When I use the foreign_keys argument to the relation
Thank you, Bobby and Michael. This seems to work now.
I'm still waiting for your book, Michael. Hope it comes soon!
A.
On Jun 12, 5:29 pm, Michael Bayer mike...@zzzcomputing.com wrote:
the foreign keys argument as yet is not propagated to the backref (the
primaryjoin is), I should look into
Thanks for the feedback it ended up being really helpful.
I think we are going to try a dev branch using joined table
inheritance and at least do some testing, because at this point there
are only three or four subtypes that we currently know about.
Also in our new schema the data will be more
19 matches
Mail list logo
