[sqlalchemy] Re: M2M relationship
Hi Michael, declarative places a convenience __init__ that installs keywords as attributes, but you're free to override this constructor with anything you'd like. Thank you for confirming this for me, I'd hoped I'd be able to override the class constructor, I often use it for considerably more than basic property setting and it would be a shame if declarative had upset that. I'm still yet to solve this problem, don't have any ideas what I'm doing wrong do you? Did you see the code examples I attached? Am I approaching this in the correct manor? Thanks, Heston --~--~-~--~~~---~--~~ 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: M2M relationship
i'm sorry for my misleading reply;( i was kind of too sleepy last night;P On Jul 13, 5:29 pm, Heston James - Cold Beans [EMAIL PROTECTED] wrote: Hi Michael, declarative places a convenience __init__ that installs keywords as attributes, but you're free to override this constructor with anything you'd like. Thank you for confirming this for me, I'd hoped I'd be able to override the class constructor, I often use it for considerably more than basic property setting and it would be a shame if declarative had upset that. I'm still yet to solve this problem, don't have any ideas what I'm doing wrong do you? Did you see the code examples I attached? Am I approaching this in the correct manor? Thanks, Heston --~--~-~--~~~---~--~~ 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: M2M relationship
i'm sorry for my misleading reply;( i was kind of too sleepy last night;P No problem my man. Heston. --~--~-~--~~~---~--~~ 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: problem with server_default (and/or sa.PassiveDefault in 0.5.beta1
It fails with fields of date. It shows:
created_at=*datetime.datetime(2008, 7, 13, 13, 59, 57)*
On Jun 21, 7:25 pm, Michael Bayer [EMAIL PROTECTED] wrote:
that __repr__ is pretty tortured too; a typical ORM-agnostic approach
is:
def __repr__(self):
return %s(%s) % (
(self.__class__.__name__),
', '.join([%s=%r % (key, getattr(self, key))
for key in sorted(self.__dict__.keys())
if not key.startswith('_')]))
--~--~-~--~~~---~--~~
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] Possible bug with Column.autoincrement in 0.5.0beta1
Hi,
I'm not sure if this is really a bug but at least it's not intuitive... :)
I'm trying to determine if the primary key for a table will be
autogenerated by the database or not by peeking into
Column.autoincrement, however, the following unit test fails:
import unittest
from sqlalchemy import Table, Column, types, MetaData
meta = MetaData()
table_autoincr = Table(some_table, meta,
Column('id', types.Integer, primary_key=True),
Column('somefield', types.String),
)
table_no_autoincr = Table(country, meta,
Column('code', types.String(2), primary_key=True),
Column('name', types.String),
)
class TestAutoincrementFlag(unittest.TestCase):
def test_table_with_serial_pk(self):
self.failUnless(table_autoincr.c.id.autoincrement)
def test_table_with_non_serial_pk(self):
# This one fails
self.failUnless(not table_no_autoincr.c.code.autoincrement)
if __name__ == '__main__':
unittest.main()
Are my assumptions wrong or is this really a bug? If the former, what
would be the correct way to determine if I can safely omit a column
value on an insert?
Thanks
Alberto
--~--~-~--~~~---~--~~
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: Setting up eager loading after query runs
On Sunday 13 July 2008 08:14:47 Kyle Schaffrick wrote: On Sat, 12 Jul 2008 22:01:50 +0300 [EMAIL PROTECTED] wrote: after the Query is long gone? if it is really gone/done, who should eager-load? I assume that it would be possible to do it after the Query is gone, at least in theory, since lazy-loaded attributes are able to trigger eager-loads on attributes of their instances, even after the Query is gone. So in essence I am trying to figure out if it's possible to add the eagerload to an instance after-the-fact. i'm trying to understand what exactly u want... do u want (for an a.b.c.d chain) to query on a (with b being lazy), then _later_ tell b.c.d to be eagerloaded and then lazyload b? i.e. some sort of options-of-relation-loading like those of-query-loading? taking a relation closer to a query in a way? like a temporary/dynamic version of current mapper/relation-options of sorts. --~--~-~--~~~---~--~~ 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: Setting up eager loading after query runs
On Sunday 13 July 2008 21:46:24 Kyle Schaffrick wrote:
On Sun, 13 Jul 2008 19:02:03 +0300
[EMAIL PROTECTED] wrote:
I assume that it would be possible to do it after the Query is
gone, at least in theory, since lazy-loaded attributes are able
to trigger eager-loads on attributes of their instances, even
after the Query is gone. So in essence I am trying to figure
out if it's possible to add the eagerload to an instance
after-the-fact.
i'm trying to understand what exactly u want...
do u want (for an a.b.c.d chain) to query on a (with b being
lazy), then _later_ tell b.c.d to be eagerloaded and then
lazyload b? i.e. some sort of options-of-relation-loading like
those of-query-loading? taking a relation closer to a query in a
way? like a temporary/dynamic version of current
mapper/relation-options of sorts.
Yeah, exactly. IOW, I would like to get the exact same behavior as
doing this:
a = sess.query(A).options(eagerload('c')).first()
foo = a.b # triggers eagerload of c
A handful of the codepaths where I'm querying for the objects are
generic functions that service queries for many different classes
for other parts of the app; the gist of all of them is this:
def generic_query_pattern(sess, class_, pk):
# ..generic logic I wish to reuse..
instance = sess.query(class_).get(pk)
# ..more generic logic involving instance..
return instance
Adding logic for the eagerload there would be my absolute last
ditch solution since it would be so messy and defeat the generic
part. Hence why I'm wondering if it's possible to do it by only
accessing the instance a:
a = generic_query_pattern(sess, A, a_key)
# Do something here, so that a pattern like this..
abcs = [ each_b.c for each_b in a.b ]
# ..isn't O(n) queries
Or, since I'm being more concrete now, if there is some other way
to architect generic_query_pattern such that I can accomplish this,
I'm open to that too.
ah,..
double-dispatch of sorts?
where/when is the knowledge of what should be eagerloaded?
split the whole-obj-commune structure by that party and give it as
argument...
or, in other words, turn the tables: dont give class/pk/whatever to
generic_func, give generic_func to something that knows better the
context of object's usage.
--~--~-~--~~~---~--~~
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: Setting up eager loading after query runs
i'm trying to understand what exactly u want...
do u want (for an a.b.c.d chain) to query on a (with b being
lazy), then _later_ tell b.c.d to be eagerloaded and then
lazyload b? i.e. some sort of options-of-relation-loading like
those of-query-loading? taking a relation closer to a query in a
way? like a temporary/dynamic version of current
mapper/relation-options of sorts.
Yeah, exactly. IOW, I would like to get the exact same behavior as
doing this:
a = sess.query(A).options(eagerload('c')).first()
foo = a.b # triggers eagerload of c
A handful of the codepaths where I'm querying for the objects are
generic functions that service queries for many different classes
for other parts of the app; the gist of all of them is this:
def generic_query_pattern(sess, class_, pk):
# ..generic logic I wish to reuse..
instance = sess.query(class_).get(pk)
# ..more generic logic involving instance..
return instance
in most complex cases things like this end up being a class,
with generic logic 1, instantiation, generic logic 2, etc pieces
being methods called in one procedure/algorithm, and whoever wants
to screw up say the instantiation, subclass that and do whatever.
this allows one to literaly assemble functions from pieces without
losing the whole idea into awful details.
--~--~-~--~~~---~--~~
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: Setting up eager loading after query runs
if u want i can give u example tomorrow on the turning the tables. i did such thing yesterday on my bitemporal query-lib, turning a loop inside out like a coat, plus adding extra entry point. but it might be dense to digest, my style is to not write anything twice if it can be said once (eh and that sometimes is quite longer). --~--~-~--~~~---~--~~ 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] srid autodiscovery mechanism
Hello
I created my own type, Geometry, to deal with PostGIS' geometry column type.
class Geometry(TypeEngine):
def __init__(self, srid=-1, dims=2):
super(Geometry, self).__init__()
self.srid = srid
self.dims = dims
def get_col_spec(self):
return 'GEOMETRY()'
def compare_values(self, x, y):
return x.equals(y)
def convert_bind_param(self, value, engine):
convert value from a geometry object to database
if value is None:
return None
else:
return SRID=%s;%s % (self.srid, value.wkb.encode('hex'))
def convert_result_value(self, value, engine):
convert value from database to a geometry object
if value is None:
return None
else:
return loads(value.decode('hex'))
So far, so good; user can do:
wifi_table = Table('wifi', metadata,
Column('the_geom', Geometry(4326)),
autoload=True)
But ultimately I'd like that my users can do:
wifi_table = Table('wifi', metadata, autoload=True)
I tried this:
from sqlalchemy.databases import postgres
postgres.ischema_names['geometry'] = Geometry
This is ok, but during reflection, when SQLA creates Geometry objects,
it obviously passes no srid argument to the Geometry constructor, so
the Geometry objects all end up with the srid property set to -1.
The proper srid value to pass to the Geometry constructor is
actually in a PostGIS table (geometry_columns). So if a geometry
column is discovered, the table's srid value could be read from that
table and passed to the Geometry constructor. I thought about doing
something like that:
from sqlalchemy.databases import postgres
def geometry_factory():
// go read srid associated with table from geometry_columns
srid =
return Geometry(srid)
postgres.ischema_names['geometry'] = geometry_factory
but geometry_factory doesn't have any connection object to go read the
srid value.
My question is simple: do you see solutions to my problem?
Thanks,
--
Eric
--~--~-~--~~~---~--~~
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: M2M relationship
On Jul 13, 2008, at 5:29 AM, Heston James - Cold Beans wrote: Hi Michael, declarative places a convenience __init__ that installs keywords as attributes, but you're free to override this constructor with anything you'd like. Thank you for confirming this for me, I'd hoped I'd be able to override the class constructor, I often use it for considerably more than basic property setting and it would be a shame if declarative had upset that. I'm still yet to solve this problem, don't have any ideas what I'm doing wrong do you? Did you see the code examples I attached? Am I approaching this in the correct manor? what I see immediately is that you're declaring mutliple declarative_bases and multiple MetaData objects. All of the Table objects which relate to one another need to share the same underlying MetaData object, and the declarative_base() function also uses a MetaData object which it creates for you, unless one is passed. So you need a global module everyone works from which starts with something like: meta = MetaData() Base = declarative_base(metadata=meta) then every Table uses the above meta as its metadata argument, every declared mapped class inherits from Base. --~--~-~--~~~---~--~~ 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: Possible bug with Column.autoincrement in 0.5.0beta1
On Jul 13, 2008, at 9:49 AM, Alberto Valverde wrote: Hi, I'm not sure if this is really a bug but at least it's not intuitive... :) I'm trying to determine if the primary key for a table will be autogenerated by the database or not by peeking into Column.autoincrement, however, the following unit test fails: autoincrement just defaults to True. It isn't consulted for a String-based column during DDL generation. The docstring for Column describes its behavior in more detail. --~--~-~--~~~---~--~~ 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: Little Bug - orm.object_mapper.get_property
On Jul 13, 2008, at 1:38 PM, Kless wrote: *orm.object_mapper* has an argument called 'raiseerror', and it works ok. *orm.object_mapper.get_property* also has an argument called 'raiseerror' (that says on documentation), but it fails: *unexpected keyword argument 'raiseerror'*. It's using as argument: 'raiseerr'. I dont like those raiseerror flags very much and in reality I'd like to take them out. Although I am not seeing the get_property() documentation you're referring to, in both 0.4 and 0.5 the docstring does not describe the arguments for that method. --~--~-~--~~~---~--~~ 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: tree/graph persistency, concurency-safe?
On Jul 13, 2008, at 1:47 PM, [EMAIL PROTECTED] wrote: hi all i have a tree/graph of nodes and links inbetween (= explicit m2m), and many users can simultaneusly change nodes/links. i need to get all-reachable-from-x in one query - so i'm saving also all the paths (not just the immediate neibourghs). i think this was called nested-sets or whatever. The question is, (how) can i do that concurency-safe. is version_id a viable/usable solution (can it happen that some poor guy is never able to save his stuff as others always overtake him)? nested sets is awful for concurrency since any node additions or deletions require a full UPDATE of at least half the table's rows. But when you say saving all the paths that sounds more like materialized path. Which I haven't used in a super long time but also would require many large UPDATEs if the tree structure is changing. Depending on what kind of performance you need you can maybe lock the whole table, or queue all the updates/deletes into a single thread/ process..otherwise you might want to look into decreasing the amount of interdependent rows if you want to use version_id or row locking. These are just guesses though without much deep thought put into it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
