[sqlalchemy] Re: last_inserted_ids()

2007-07-08 Thread alex bodnaru

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


hello,

i was following this thread with interest, and found that
last_inserted_ids returns the oid of the inserted record.

can i portably retrieve a record by this oid?

alex

mc wrote:
> here is a working script, (need to change connection parameters , of
> course).
> When I run it the output is:
> [1L]
> [2L]
> 
> Excpected according to documentation:
> ['Jack']
> ['Jill']
> 
> ###
> 
> from sqlalchemy import *
> db=create_engine('mysql://user1:[EMAIL PROTECTED]/tests')
> 
> create_s = """
> CREATE TABLE `users` (
> `user_name` varchar(16)  NOT NULL ,
> `ID` int unsigned NOT NULL auto_increment,
> PRIMARY KEY  (`user_name`),
> UNIQUE (`ID`)
> ) ENGINE=InnoDB
> """
> 
> db.execute("DROP TABLE IF EXISTS `users`")
> db.execute(create_s)
> 
> md=BoundMetaData(db)
> t=Table('users', md, autoload = True)
> 
> r = t.insert().execute(user_name='Jack')
> print r.last_inserted_ids()
> 
> r = t.insert().execute(user_name='Jill')
> print r.last_inserted_ids()
> 
> ###
> 
> 
> On Jul 6, 4:24 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>> On Jul 6, 2007, at 4:33 AM, mc wrote:
>>
>>
>>
>>> I am using 0.3.6  and reading the 0.3 doc.
>>> The problem is that actually I need it the way it works for me now,
>>> i.e. returning the auto_increment fields and not my primary key
>>> fields.
>>> Will upgrading sqlalchemy break this (undocumented) feature?
>> as I said, i dont think what you describe is possible - only columns
>> explicitly marked as "primary key" get placed into last_inserted_ids
>> ().  a column that is only auto_increment will not be placed in this
>> result.  please send a working test script which illustrates the
>> behavior you are seeing.
> 
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRpE0I9pwN1sq38njAQJxvwP+M9m1YErgTRp6oPCk79JdlkL8BbIjda5a
Nsy0aEyiq5/oOvqP0mClGCjVNWvMVCdAH0+Sy9O5hOHkWEBGEjVIQ3A78QqjqOjM
eVQ2e/Ngfmgr1TwqQPe9TIpxhp5U3cqEWWHULOvKiK2f0ZwhatPEBBjMy3cRmOjB
Yg2MrWg1ywY=
=RRu3
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: last_inserted_ids()

2007-07-09 Thread alex bodnaru

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


hi mike,

i have installed the 0.3.9 from svn, and now it's returning the primary
key values of the last inserted record, as documented, even if those are
not numeric.

thanks a lot!

though i'm on a well packaged debian system, i have a lib deirectory
ahead of PYTHONPATH for last minute functionality as this.

could i make the sqlalchemy subdirectory updateable by svn, or should i
re-egg the updated package after every significant change?

best regards an thanks again,

alex

Michael Bayer wrote:
> 
> On Jul 8, 2007, at 2:59 PM, alex bodnaru wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>> hello,
>>
>> i was following this thread with interest, and found that
>> last_inserted_ids returns the oid of the inserted record.
>>
>> can i portably retrieve a record by this oid?
>>
> 
> no.  it does not return OID, it returns whatever was last inserted as  
> a primary key value.  in the case of mysql as well as sqlite tables  
> which have an integer primary key, its synonymous with "OID" on those  
> databases.  but this is an implementation detail of those particular  
> databases.
> 
> 
> 
> > 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRpIwQNpwN1sq38njAQKbIQP+NCkq0Xog6fvhWg8tPlBasickCvliTwxA
QByk+ePDngGTcKfObBiwNolIf9sJ2/8p9zKI3vQ9dCBicGvPMjqfji3FalRC1Yl8
nP537siQGf6FYvfKhA9nhfp01tOuBdVEVrTQgAYvNB7VW3igb0ZwGqVluswScacw
LAxarfdJaEc=
=nmBF
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] problem with whereclause

2007-07-09 Thread alex bodnaru

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


hi all,

i'm using sa 0.3.9 from svn for the new last_inserted_ids functionality.

after upgrading from official 0.3.8 i have encountered the following
problem:

since i'm calling a select statement using whereclause with bindparams,
its execution depends on a dictionary of fields to compare with.

in 0.3.8, only the bound fields would be considered in the whereclause,
while other keys in that dictionary were ignored. this is the behaviour
i understood will be in 0.4, instead of select_by.

in 0.3.9, all the field-value pairs in the execute dictionary are being
considered part of the where with checking for equality, with no reason.

a more severe form of this problem raises, where i wish to use an update
sentence with both where clause and values, receiving bindparam. then, i
definitely would use a dictionary in execute for values and where
conditions, according to their bindings, but i have only one dictionary
in execute.

best regards,

alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRpLNZNpwN1sq38njAQL/IgQAlu1dKYK2sx6OfsuKwngW9t6/IlFVVyny
hmtR+IpyjgTQzzzagLBick5Gqvpn/LdJLUbY8HKy33To+VfgyMpBeWgxoR1qC9z2
kd1nbNVfZhBN7Eqm0G2LX+PR0/pkJrPNCPGVdKgY0c5obDTiirEPH/mTJBbycJAO
0zfAyXTj3ZY=
=QwRP
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] eagerloading stops due to recursion check

2007-07-16 Thread non-alex

Hello
I found conditions when eagerloading does not work because of
recursion check in setup_query (strategy.py) method.
Say I have classes A,B,C
and
A_mapper has properties a_to_b_property1, a_to_b_property2,
B_mapper has property b_to_c_property.
When I make something like
query(A).options(eagerload('a_to_b_property1'),eagerload('a_to_b_property1.b_to_c_property'),eagerload('a_to_b_property2')).get(...)

After processing two first eagerload properties, B_mapper is in
recursion stack
and a_to_b_property2 cannot modify query statement.

Any other way to check recursion detection?

Thanks


--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: eagerloading stops due to recursion check

2007-07-16 Thread non-alex

Sorry, i'll try to be precise.

table_A contains two distinct foreign keys to table_B, table_B
contains one foreign key to table_C
mapped classes are A, B, C.
mapper_A contains two corresponding properties a_to_b_property1,
a_to_b_property2 to class B.
mapper_B contains property b_to_c_property


I cannot eagerload all three properties in session.query(A)... !

look at this lines (strategies.py, setup_query):

464if self.mapper in context.recursion_stack:
465return
466else:
467context.recursion_stack.add(self.parent)

After processing eagerload property 'a_to_b_property1. 
b_to_c_property',
context.recursion_stack contains B_mapper (as a parent of  
b_to_c_property) - line 467
so 'a_to_b_property2' just skipped - line 464.

I want to load all this relations in one query.



--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: eagerloading stops due to recursion check

2007-07-16 Thread non-alex



On 16 июл, 19:26, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jul 16, 2007, at 10:41 AM, non-alex wrote:

> yeah...we dont currently support eager loading across cyclical  
> relationships.  

Well, i thought that my example does not concern cyclical relations.
In my case, relation paths are
A-(foreign key1)->B->C
A-(foreign key2)->B
and not, say, A->B->A.
So "depth" parameter not needed.
But If you do not object to alter eagerloading, including cyclical
relations, I'll wait the new version.

One more question about 0.4 version.
I want to refresh attributes of large collection of objects.
Session refresh/expire/load will be  too slow - many queries.
Session.clear() seems to be overkill - ALL objects removed from
session -right?
You discouraged to use always_refresh (I agree with it).
I found this 'unofficial' recipe in mailing list:
result =
query._select_statement(query.compile(),populate_existing=True)
How can I do massive refresh by one query (including eager loading) in
0.4 version?




In some thread, you said that


--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: eagerloading stops due to recursion check

2007-07-16 Thread non-alex

I think something like
context.recursion_stack.add((self.parent,self.key))
enstead of context.recursion_stack.add(self.parent)
will work.
I post a ticket #659.


--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] confusing populate_existing

2007-08-02 Thread non-alex

Hi!
I'm using queries with populate_existing modifier, and found this
problem:
I issue a query with populate_existing and some eagerload chain,
ending with class C.
C is refreshed, and have some foreign key attribute changed correctly.
But relation based on that key, if already loaded, will not lazy load
again, and still points to WRONG (old) instance.
This is test:

def test_populate_existing_with_eager(self):
s = create_session()
addr = s.query(Address).get(1)
order = s.query(Order).get(1)
old_user = s.query(User).get(7)
assert addr.user == old_user #lazy loading user attribute

#Now change the address
addresses.update(addresses.c.id == 1).execute(user_id=9)
new_user = s.query(User).get(9)
#Refreshing Odrder and Address instances
order =
s.query(Order).populate_existing().options(eagerload('address')).filter_by(id=1).one()
#Important! addr.user was already loaded!
assert addr.user_id == 9# refreshed ok
assert addr.user == new_user , 'Fail! still == old_user, need
to lazy load it again...'

Same problem with many_to_many relations, but it's more complex to
solve.


--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: Hierachical data

2007-08-04 Thread Alex Conrad

Hi again,

On Aug 4, 5:41 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:



> no, youre free to order by whatever crierion youd like.  the examples
> return the nodes in insert order and will duplicate the input document.



> you can order by whatever you like.  the example is ordering in the
> identical order as the source document but this can be changed.



> er, records are inserted in the order they're read from the source XML.

The XML I showed was just an example to illustrate my problem. Sorry
if this was confusing. Right now, I have an application that uses XML,
it's true, but I'm rewriting the whole application. So I just won't
have any XML input. I need to create a playlist _from_scratch_ stored
in a database; no XML (I will later export the playlist from the
database to XML, but that's another thing). I did see that the example
you provided takes an XML file as input. The tree is walked and
translated to the database. So you're able to keep the order as each
node is inserted one by one as the XML file is beeing traversed, which
naturally makes increments of the integer primary key ID field. But it
won't work like this for me.

> if you wanted to support direct mutation operations on Node objects
> without mass deletes/inserts, add an "orderby" column to the nodes
> table and use a recipe like OrderingList:  http://www.sqlalchemy.org/
> docs/plugins.html#plugins_orderinglist
>
> hope this helps...

Aaah, yes, this might help. I'll have to look on that orderinglist. It
apparently does exactly what I need. Thanks !

Regards,
Alex


--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---