Hello I have 2 tables: data and acquisitions,
- each Acquisition has many Data
- each Data come from a different sensor
- the single sensor is identified by the couple Acquisition.id_centr,
Data.id_meas
No I need a query with one colum for each sensor and a row for each
Acquisition.datetime
This
Thank you all... As soon as I have the webserver where I'm going to
use that structure up and running, I'll try it and i'll let you
know...
2010/12/13 Laurent Rahuel laurent.rah...@gmail.com:
Hello,
You should also take a look at http://pypi.python.org/pypi/sqlamp/0.5.2, an
implementation of
An update. This problem does occur with sqlite it's just that sqlite
doesn't enforce the foreign key so it doesn't throw an exception.
# output that deletes in the proper order
2010-12-15 14:33:52,197 INFO sqlalchemy.engine.base.Engine.0x...d050
BEGIN (implicit)
2010-12-15 14:33:52,197 INFO
This is an interesting edge case and I can probably ensure that the dependency
between Parent/Child is present in the unit of work even if there is no known
linkage at the Child.parent level for the objects actually present - ticket
#2002 is added for this.
In the meantime, the uow needs to be
Wow, this has been a problem for me for the past 3 or 4 days and took
a while to get to that example. Defining the backrefs or the
relationships in the opposite direction did the job. I had
intentionally left out some of the backreffed relationships because I
didn't need them for what I was
It was in fact a one liner, so you can go back to your original code if you use
the latest 0.6 tip:
http://hg.sqlalchemy.org/sqlalchemy/archive/rel_0_6.tar.gz
thanks for the bug report !
On Dec 15, 2010, at 3:41 PM, Will Weaver wrote:
Wow, this has been a problem for me for the past 3 or 4
Why does Session.merge only look at primary key and not all unique
keys?
Leaving aside some irritating DBMS restrictions on PKs and some
automatic indexing that tends to happen, the PK is not fundamentally
different than other unique keys and I don't see why SQLA
distinguishes them from an
Whoops - my clipboard had an old pre-cleaned sample code in it that I
pasted. Sorry about the excess lines... maybe the logging mod will be
useful for some people, though?
The code is still right, just not fully cleaned up. The first Column
config is the one that works around the Sqlite
On Dec 15, 2010, at 5:14 PM, Russell Warren wrote:
Why does Session.merge only look at primary key and not all unique
keys?
Well the theory of operation regarding merge() is based on that of the identity
map, which is linked to object/row identity. Consider that it also
cascades along
On Dec 15, 2010, at 9:04 AM, neurino wrote:
Hello I have 2 tables: data and acquisitions,
- each Acquisition has many Data
- each Data come from a different sensor
- the single sensor is identified by the couple Acquisition.id_centr,
Data.id_meas
No I need a query with one colum for each
Why does Session.merge only look at primary key and not all unique
keys?
Well the theory of operation regarding merge() is based on that of
the identity map, which is linked to object/row identity.
Consider that it also cascades along relationship paths. It would
be a difficult operation
In an application that is heavy on inserts and updates, cProfile
output is dominated by Session.add in which about 45% of time is
spent. Most of that time, in turn, is spent in cascade_iterator (43%).
I can provide more detailed information if needed.
The application does aggressive caching of
12 matches
Mail list logo
