comments on this ?
jean-philippe dutreve wrote:
It would be fine/safe that accountA has entry removed BEFORE any
reload (with explicit refresh/expire/commit). I can't remember, but a
previous version of SA had this behavior.
On Apr 6, 4:42 pm, Michael Bayer mike...@zzzcomputing.com wrote
is contained in 2 accounts temporaly.
It can lead to false computation (when summing balance for instance).
On 5 avr, 22:03, jason kirtland j...@discorporate.us wrote:
jean-philippe dutreve wrote:
Hi all,
I wonder if SA can handle this use case:
An Account can contain Entries ordered by 'position
variations on business
rules for moving an item that would be difficult to encapsulate in a common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
Currently, I use accountA.remove(entry) and I have rewritten insort to
bypass
be many variations on business
rules for moving an item that would be difficult to encapsulate in a
common
operation within SA.
--
Mike Conley
On Mon, Apr 6, 2009 at 2:10 AM, jean-philippe dutreve
jdutr...@gmail.comwrote:
Currently, I use accountA.remove(entry) and I have
Hi all,
I wonder if SA can handle this use case:
An Account can contain Entries ordered by 'position' attribute.
mapper(Account, table_accounts, properties = dict(
entries = relation(Entry, lazy=True, collection_class=ordering_list
('position'),
order_by=[table_entries.c.position],
. The below will break, if and when that's fixed to
match the pure Python implementation in the standard lib.
Calling list.extend(account_entries, new_entries) is probably a safe
alternative.
*http://bugs.python.org/issue3935
jean-philippe dutreve wrote:
What I've done is something like
attribute can't be trusted to be in sync
with the list order.
jean-philippe dutreve wrote:
Below is the profiling of code that added 1200 items into an
ordering_list relation. I had to bypass the ordering_list stuff for
bulk additions in order to have better performance (down to 2
seconds
I'd like to delete all Transactions contained in an account hierarchy
without loading any transaction into memory, just DB work with the SQL
DELETE request constructed by SA.
The query that defines the transactions is:
Session.query(Transaction).join(['entries','account','root'],
fine. thank you for your help.
jean-philippe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send
After debugging, i've noticed that the issue is related to eager
loaded
relations. If you try the example script with _descendants relation
having lazy=None or True, then the extension method is not called
anymore.
Is there a way to fire the extension method even without eadger
loading?
i cant
Thank you for your support. You have done an awesome work overall.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe
Hi all,
I'm trying to load a whole Tree of Account objects (Mapped instances)
in a single SELECT with unlimited depth.
I'm using PostgreSQL connectby function from the tablefunc module.
It returns rows of each nodes in a depth first visit.
sql =
SELECT acc_accounts.* FROM
Thank you for the suggestion but the extension method doesn't fired,
even without raw sql:
mapper(Account, table_accounts, extension=AccountLoader(),
properties=dict(
children = relation(Account, lazy=None,
primaryjoin=table_accounts.c.parent_id==table_accounts.c.account_id,
Here's my issue: 3 tables
CREATE TABLE accounts (
account_id serial PRIMARY KEY,
name varchar(16) NOT NULL UNIQUE,
);
CREATE TABLE transactions (
transaction_id serial PRIMARY KEY,
);
CREATE TABLE entries (
entry_id serial PRIMARY KEY,
account_id integer NOT NULL REFERENCES
Here's my issue: 3 tables
CREATE TABLE accounts (
account_id serial PRIMARY KEY,
name varchar(16) NOT NULL UNIQUE,
);
CREATE TABLE transactions (
transaction_id serial PRIMARY KEY,
);
CREATE TABLE entries (
entry_id serial PRIMARY KEY,
account_id integer NOT NULL REFERENCES
Ive uploaded the script eagerload_all.py that reproduce the issue.
Hope it helps you.
On 11 sep, 16:43, Michael Bayer [EMAIL PROTECTED] wrote:
On Sep 11, 2007, at 10:28 AM, Jean-Philippe Dutreve wrote:
The name is on account, not on entry.
Transactions and all must be loaded in one shot
its actually not eager loading the second list of accounts
If there is no eager loading on the second list, I don't understand
why a 'SELECT entries ...' is executed when I just
ask account.name and not account.entries.
untested, i.e. join_depth on a mapper thats not self-referential,
Another solution could be to inverse the order:
- first delete the parent (so the rule RESTRICT is immediately fired)
- second set null the FKs.
On 8 sep, 19:52, Michael Bayer [EMAIL PROTECTED] wrote:
On Sep 8, 2007, at 12:54 PM, Jean-Philippe Dutreve wrote:
My need is related
My need is related to Postgresql ON DELETE RESTRICT/NO ACTION : I'd
want a sql exception as soon as a parent having any existing child is
deleted. I don't want cascade delete on children, just the parent but
only if it has no child.
I've remarked that SA (0.4) first SET NULL all FKs in child
Thanks Jason for your clear explanation.
Is there any mean to do your suggestion to call the pure Python
version without coping/pasting it into my module?
On 7 sep, 16:28, jason kirtland [EMAIL PROTECTED] wrote:
Jean-Philippe Dutreve wrote:
I was using SA 0.3.9 to insert an item in an ordered
It seems that the bug fixed by changeset 2795 (column_prefix with
synonym) is still active in 0.4 branch.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
21 matches
Mail list logo
