Hi! Tried searching around for information on this topic but couldn't
find anything, so here's the question: is it possible to use passive
deletes with joined table inheritance? Setting the
'ondelete=CASCADE' on the foreign key declaration of the child class
primary key is trivial, however there
Hi all together!
As this is my first post a short introducion: I am an geo-engineer
working on geoinformatics, spatial databases and spatial data
infrastructure. For this I am using sqlalchemy and geoalchemy for most
database-projects. At the moment i run into an error after upgrading
to 0.7.4.
On Dec 15, 2011, at 4:06 AM, Pedro Romano wrote:
Hi! Tried searching around for information on this topic but couldn't
find anything, so here's the question: is it possible to use passive
deletes with joined table inheritance? Setting the
'ondelete=CASCADE' on the foreign key declaration of
On Dec 15, 2011, at 2:38 AM, useher wrote:
I write a library with some classes that has to bundle function for
different applications accessing data on a PostgreSQL-9.x Server.
sqlalchemy is installed and maintained by easy_install not by
packetmanagement. After upgrading to 0.7.4 the
On Dec 15, 2011, at 2:45 AM, espresso maker wrote:
Hi there,
I am in process of designing my db schema for a web service that
monitors servers on an intranet and has to store a lot of fields like
cpu, mem, load avg, swap, and plenty more for a period of time. The
fields might change in
Thank you very much for the quick reply and the advice Michael.
--Pedro.
On Dec 15, 3:27 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Dec 15, 2011, at 4:06 AM, Pedro Romano wrote:
Hi! Tried searching around for information on this topic but couldn't
find anything, so here's the
I notice no such API events as before_expunge() or after_expunge().
Hopefully without taking much of your time, can you point me in any
direction of how I might go about being notified when an object is
expunged?
Why?
There are certain states a persistent record reaches where further
changes to
On Dec 15, 2011, at 11:46 AM, Kent wrote:
I notice no such API events as before_expunge() or after_expunge().
Hopefully without taking much of your time, can you point me in any
direction of how I might go about being notified when an object is
expunged?
Why?
If we start adding events
Up front, I'm not using the ORM at all, and I'm using SQLAlchemy 0.7.4
with psycopg2 2.4.3 on PostgreSQL 8.4.10 on Linux x86_64.
I did some performance testing. Selecting 75 million rows (a straight
up SELECT colA from tableA) from a 5GB table yielded some interesting
results.
psycopg2 averaged
On Dec 15, 2011, at 12:51 PM, Jon Nelson wrote:
Up front, I'm not using the ORM at all, and I'm using SQLAlchemy 0.7.4
with psycopg2 2.4.3 on PostgreSQL 8.4.10 on Linux x86_64.
I did some performance testing. Selecting 75 million rows (a straight
up SELECT colA from tableA) from a 5GB
On 12/15/2011 12:20 PM, Michael Bayer wrote:
On Dec 15, 2011, at 11:46 AM, Kent wrote:
I notice no such API events as before_expunge() or after_expunge().
Hopefully without taking much of your time, can you point me in any
direction of how I might go about being notified when an object is
On Dec 15, 2011, at 1:01 PM, Michael Bayer wrote:
haven't clocked it but a source inspection indicates Python's would be much
slower, as it's going for much more correct and comprehensive behavior
using a linked list.
Here's our __iter__() (self._list is a native Python list):
On Dec 15, 2011, at 1:16 PM, Kent wrote:
why not use a before_flush() extension, or similarly a
before_insert/before_update/before_delete extension, and simply reject
flush() calls which include such objects in the list of those to be modified
?The fact is they still represent
On Thu, Dec 15, 2011 at 12:01 PM, Michael Bayer
mike...@zzzcomputing.com wrote:
On Dec 15, 2011, at 12:51 PM, Jon Nelson wrote:
Up front, I'm not using the ORM at all, and I'm using SQLAlchemy 0.7.4
with psycopg2 2.4.3 on PostgreSQL 8.4.10 on Linux x86_64.
I did some performance testing.
it depends on how you'd be querying for these fields. If the list of
things being collected is highly variable you might consider a key/value type
of approach (table of keys, dependent table of values).
I always want all the columns / record. Should I still go with key/
value type
On 12/15/2011 1:31 PM, Michael Bayer wrote:
Are there reasons one need to avoid referencing unloaded relationships from
within before_upate()? (I can't recall the exact problem I've had in the past
with that at the moment.)
Thanks for all the input. Regarding the issue of referencing a
On Dec 15, 2011, at 2:13 PM, Kent wrote:
On 12/15/2011 1:31 PM, Michael Bayer wrote:
Are there reasons one need to avoid referencing unloaded relationships from
within before_upate()? (I can't recall the exact problem I've had in the
past with that at the moment.)
Thanks for all the
On Dec 15, 2:39 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Dec 15, 2011, at 2:13 PM, Kent wrote:
On 12/15/2011 1:31 PM, Michael Bayer wrote:
Are there reasons one need to avoid referencing unloaded relationships
from within before_upate()? (I can't recall the exact problem
wait...that's where you lose me. In this condition where user's
changed someobject.some_related_id, then as soon as that is flushed,
someobject.some_related by definition is no longer going to be the
object we get with the currently committed id This is circling
back to the automatic
On Dec 15, 2011, at 5:05 PM, Kent wrote:
wait...that's where you lose me. In this condition where user's
changed someobject.some_related_id, then as soon as that is flushed,
someobject.some_related by definition is no longer going to be the
object we get with the currently committed id
On Dec 15, 2011, at 5:56 PM, Kent wrote:
ere is the script output for a demonstration. I can't imagine this being
the behavior we want, is it?
*** Before move: rockid=[1] rock object: Rock: id=[1]
*** During flush: rockid=[0] rock object: Rock: id=[1]
*** After
On 12/15/2011 6:29 PM, Michael Bayer wrote:
I never use before_update()/before_insert() for anything outside of direct SQL
manipulation, which is what they are intended for. That's why they get a
Connection but not a Session.
So are you suggesting if I did this all within before_flush(),
I was just having a problem with a one-to-many relationship array coming out in
the wrong order. Looking
herehttp://www.sqlalchemy.org/docs/orm/relationships.html#relationships-api,
It wasn't too hard to figure out that I needed to do:
myFoos = relationship(Foo, order_by = Foo.id)
I was
On Dec 15, 2011, at 10:15 PM, Jackson, Cameron wrote:
I was just having a problem with a one-to-many relationship array coming out
in the wrong order. Looking here, It wasn't too hard to figure out that I
needed to do:
myFoos = relationship(Foo, order_by = Foo.id)
I was a
Hi,
I have the following column_property definition
time = Column(DateTime, nullable=False)
end_time = column_property(
select([Event.duration + time]).where(Event.id==event_id)
)
where Event.duration stands for minutes and is an Integer, while time is a
DateTime
clearly,
Yeah, when I said 'id', I guess I really meant the primary key.
All of your arguments make perfect sense. Consider my mind change, it's better
how it is now!
In that case, can I suggest adding a very short explanation of the order_by
parameter here:
absolutely, the docs have a lot of shortcomings with order_by, including the
docstring for relationship not being very clear about it.there's not even a
dedicated section I can find otherwise, I think there was one not sure where it
went
On Dec 15, 2011, at 11:36 PM, Jackson, Cameron
27 matches
Mail list logo
