[sqlalchemy] Re: issue with delete(obj) and ManyToOne relations
le 02.09.2008 18:33 Michael Bayer a écrit:
> On Sep 2, 2008, at 12:06 PM, Remi Jolin - SysGroup wrote:
>
>
>> Hello,
>>
>> Here is a small example of my issue (it's Elixir syntax, but I think
>> it's not an Elixir specific issue) :
>> class Rec(Entity):
>>collection = ManyToOne('Coll')
>>
>> class Coll(Entity):
>>recs = OneToMany('Rec')
>>
>> r1 = Rec()
>> r2 = Rec()
>> c = Coll(recs=[r1,r2])
>>
>> at that time len(c.recs) == 2
>>
>> if I do something like r1.delete(), I would expect len(c.recs) == 1
>> but
>> it stays at 2 until the flush(). Am I missing some parameter on the
>> class definitions ?
>> I've tried some "cascade" parameters but they seem to handle the Recs
>> deletion when you delete a Coll.
>>
>
>
> saying r1.delete() won't automatically update the already-loaded
> "recs" collection which it's a part of. You'd instead configure
> cascade="all, delete-orphan" on "recs", so that the removal of a Rec
> from c.recs would result in its deletion. Otherwise, any activity
> which refreshes "c.recs" after a flush has occured will also do.
>
So, instead of r1.delete(), the solution could be (having configured
cascade="all, delete-orphan" on recs) to do a
r1.collection = None and let the flush() delete it because of the
cascade rules.
> I'm also not sure if the above is properly associating "recs" with
> "collection" since SQLA usually needs a "backref" keyword to work this
> out; I'm not sure what Elixir uses to indicate that.
>
Elixir handles the backrefs without the need to explicitly define them
as long as there is no ambiguity.
--~--~-~--~~~---~--~~
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] issue with delete(obj) and ManyToOne relations
Hello,
Here is a small example of my issue (it's Elixir syntax, but I think
it's not an Elixir specific issue) :
class Rec(Entity):
collection = ManyToOne('Coll')
class Coll(Entity):
recs = OneToMany('Rec')
r1 = Rec()
r2 = Rec()
c = Coll(recs=[r1,r2])
at that time len(c.recs) == 2
if I do something like r1.delete(), I would expect len(c.recs) == 1 but
it stays at 2 until the flush(). Am I missing some parameter on the
class definitions ?
I've tried some "cascade" parameters but they seem to handle the Recs
deletion when you delete a Coll.
--~--~-~--~~~---~--~~
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] max(datetime) does not return a datetime. Bug or feature ?
Hello, consider the following (Elixir syntax sorry) class A(Entity): creation_date = Field(DateTime) ... A.query().max(A.creation_date) returns a unicode and not a datetime as max([a.creation_date for a in A.query()]) returns Is it a bug ? (sqlalchemy version 0.4.6) --~--~-~--~~~---~--~~ 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 Numeric type and mysqll
le 07.09.2007 20:26 jason kirtland a écrit:
> remi jolin wrote:
>
>> le 07.09.2007 19:47 remi jolin a écrit:
>>
>>> le 07.09.2007 19:27 Michael Bayer a écrit:
>>>
>>>
>>>> numeric types are going to come out using decimal.Decimal objects in
>>>> 0.4 but not exactly sure whats happening there...do a repr(m.price).
>>>>
>>>>
>>>>
>>>>
>>> it gives Decimal("10.00")
>>>
>>> and I'm using SA 0.3.10
>>> Is there a difference regarding Numeric between 0.3.7 and 0.3.10 because
>>> the system where I have sqlite DB is using 0.3.7 ??
>>>
>>>
>> I've just tested with 0.3.10 and sqlite : repr(m.price) gives 10.0 so it
>> is not a difference due the SA versions but only DB access implementation.
>>
>
> NUMERIC columns will return Decimals on some db-apis, but not sqlite. In
> 0.4, the sqlalchemy Numeric type adapts as needed to ensure Decimal
> across all db-apis. But in 0.3, what the db-api returns is what you get
> for numerics.
>
> Comparing against Decimals will have the results you expect:
>
>>>> m.price > Decimal('12.34')
>False
>
>
Ok, thanks. I've adapted my code to deal with both cases.
> -j
>
> >
>
--~--~-~--~~~---~--~~
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 Numeric type and mysqll
le 07.09.2007 19:47 remi jolin a écrit:
> le 07.09.2007 19:27 Michael Bayer a écrit:
>
>> numeric types are going to come out using decimal.Decimal objects in
>> 0.4 but not exactly sure whats happening there...do a repr(m.price).
>>
>>
>>
> it gives Decimal("10.00")
>
> and I'm using SA 0.3.10
> Is there a difference regarding Numeric between 0.3.7 and 0.3.10 because
> the system where I have sqlite DB is using 0.3.7 ??
>
I've just tested with 0.3.10 and sqlite : repr(m.price) gives 10.0 so it
is not a difference due the SA versions but only DB access implementation.
>> On Sep 7, 2007, at 12:57 PM, remi jolin wrote:
>>
>>
>>
>>> Hello,
>>>
>>> I have the following definition (using Elixir)
>>> class Manifestation(Entity):
>>> has_field('price', Numeric)
>>> The DB is mysql
>>>
>>> and something like
>>> m = Manifestation(price=10.0)
>>>
>>> then when accessing to this manifestation again (after flush,
>>> clear, etc...)
>>> I have this strange behavior
>>>
>>>
>>>>>> m.price > 10
>>>>>>
>>>>>>
>>> False
>>>
>>>
>>>>>> m.price > 10.0
>>>>>>
>>>>>>
>>> True
>>>
>>>
>>>>>> m.price > 12.34
>>>>>>
>>>>>>
>>> True
>>>
>>> The same definition works great when using a sqlite DB.
>>> Any idea ?
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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 Numeric type and mysqll
Hello,
I have the following definition (using Elixir)
class Manifestation(Entity):
has_field('price', Numeric)
The DB is mysql
and something like
m = Manifestation(price=10.0)
then when accessing to this manifestation again (after flush, clear, etc...)
I have this strange behavior
>>> m.price > 10
False
>>> m.price > 10.0
True
>>> m.price > 12.34
True
The same definition works great when using a sqlite DB.
Any idea ?
--~--~-~--~~~---~--~~
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: backref definitions
le 27.06.2007 15:36 Michael Bayer a écrit:
> On Jun 27, 2007, at 6:00 AM, remi jolin wrote:
>
>
>> Hello,
>>
>> Suppose we have the Address and User mappers as they are defined in
>> SA's
>> documentation
>>
>> I was wondering if the 2 syntax bellow were equivalent :
>>
>> 1/
>> User.mapper.add_property('addresses', relation(Address,
>> backref=BackRef('user', **user_args)), **addresses_args)
>>
>> 2/
>> Address.mapper.add_property('user', backref='addresses', **user_args)
>> User.mapper.add_property('addresses', backref='user',
>> **addresses_args)
>>
>>
>
> no, they are not. the example in 2. is incorrect. you only need one
> property with a backref to set up the bi-directional relationship.
> setting both properties in both directions will have the effect of
> only some of the properties taking effect..and in an undefined way
> (i.e. it might break).
>
Thanks Mickael,
I first tried to add the backref on only one side but the relationship
was not bi-directional ; user.addresses.append(a) updated address.user
but not the other way, that's why I added it both sides.
Then, with backrefs defined on both "add_property", I had a look at the
structures created at the mapper level (properties, reverse_property,
...) and they seemed coherent but I was not sure it was enough.
The only difference I saw is that you could find the backref "field" in
the properties list of both sides but the PropertyLoader objects were
coherent (User.mapper.properties['addresses'].reverse_property ==
Address.mapper.properties['user'] and
Address.mapper.properties['user'].reverse_property ==
User.mapper.properties['addresses']) and is_backref was positionned on
one side and not the other as you say it is needed below...
> the two equivalent conditions you have in mind are:
>
> User.mapper.add_property('addresses',
> relation(Address, backref=backref('user', **user_args)),
> **addresses_args)
>
> and
>
> Address.mapper.add_property('user',
> attributeext=attributes.GenericBackrefExtension('addresses'),
> is_backref=True, **user_args)
> User.mapper.add_property('addresses',
> attributeext=attributes.GenericBackrefExtension('user'),
> **addresses_args)
>
> where GenericBackrefExtension handles bi-directional attribute
> population, i.e. someaddress.user = User() firing off
> someaddress.user.addresses.append(someaddress), and the "is_backref"
> flag is needed to be on one side of the bi-directional relationship
> in some cases during a flush() (currently, only in post_update
> relations).
>
>
OK, I'll do it that way if it is the supported way. Thanks for the hint.
Does the "is_backref" needs to be on a specific side of the relation ??
--~--~-~--~~~---~--~~
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] backref definitions
Hello,
Suppose we have the Address and User mappers as they are defined in SA's
documentation
I was wondering if the 2 syntax bellow were equivalent :
1/
User.mapper.add_property('addresses', relation(Address,
backref=BackRef('user', **user_args)), **addresses_args)
2/
Address.mapper.add_property('user', backref='addresses', **user_args)
User.mapper.add_property('addresses', backref='user', **addresses_args)
--~--~-~--~~~---~--~~
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: selectresults and activemapper : behavior changes between versions 0.3.1 and 0.3.6
Michael Bayer a écrit : > On Apr 30, 2007, at 9:42 AM, remi jolin wrote: > > >> Hello, >> >> I'm using selectresults and activemapper. >> in version 0.3.1 if I did something like x = >> Announces.select(Annonces.c.type=="A") I got a SelectResults object. >> Now (0.3.6) I get a list of Announces (the query is done immediately). >> But if I don't specify anything in the select method >> (Announces.select()) I get the expected SelectResults object. >> >> Is it the expected behavior ? >> >> > > its not. I can see a small bug in SelectResultsExt that might lead > to this issue, so try out 2588 for that. > Ok, it works. Thanks Michael. > however, SelectResults is deprecated since all of its functionality > is available within Query. if you instead call Announces.query.filter > (Annonces.c.type=="A") that would be the new usage. > isn't it Announces.query().filter(Annonces.c.type=="A") because your syntax gives an error "AttributeError: 'function' object has no attribute 'filter'" TurboGears paginate is using SelectResults, not (V 1.0.1) Query. > not to mention that ActiveMapper is deprecated in favor of Elixir > too :) . > Yes I know but my project is older than Elixir ;-) --~--~-~--~~~---~--~~ 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] selectresults and activemapper : behavior changes between versions 0.3.1 and 0.3.6
Hello, I'm using selectresults and activemapper. in version 0.3.1 if I did something like x = Announces.select(Annonces.c.type=="A") I got a SelectResults object. Now (0.3.6) I get a list of Announces (the query is done immediately). But if I don't specify anything in the select method (Announces.select()) I get the expected SelectResults object. Is it the expected behavior ? --~--~-~--~~~---~--~~ 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: Stuck creating a custom relation using ActiveMapper
Hello,
Paul Johnston a écrit :
> Hi,
>
> I'm trying to create a relation like this
>
> Testing [1] -> [many] Target (where target.is_testtgt==0)
>
> i.e. I want to map only to Target rows that match the where condition.
>
> Now, this is easy enough using assign_mapper:
>
> assign_mapper(ctx, Testing, testing, properties={ 'targets':
> relation(Target,
> primaryjoin=((target.c.testingid==testing.c.id) &
> (target.c.is_testtgt != 1))) } )
>
> However, I'm using ActiveMapper. I can't do the same, as the relation
> needs to use Testing.c.id , and at that point
> Testing isn't defined, causing this to error:
>
> target = one_to_many('Target', colname='testingid',
> backref='testing', primary_join=(( Testing.c.id==Target.c.testingid) &
> (Target.c.is_testtgt != 1)))
>
> So, I thought I'd add the relation later on. Again, this is easy with
> assign_mapper:
>
> mp.properties['target'] = relation(Target,
> primaryjoin=((Target.c.testingid == Testing.c.id
> ) & (Target.c.is_testtgt != 1)) )
>
> And that works fine. I thought to do the equivalent with ActiveMapper:
>
> class_mapper(Testing).properties = {'target': relation(Target,
> primaryjoin=((Target.c.testingid == Testing.c.id
> ) & (Target.c.is_testtgt != 1)) ) }
>
Have you tried :
Testing.mapper.add_property('target', relation(Target, primary))
(of course after having defined the Testing and Target classes...)
> But then "Testing.get(1234).targets" gives an AttributeError.
>
> So, is there any way to achieve this using ActiveMapper? Any help
> appreciated.
>
> Paul
>
> >
--~--~-~--~~~---~--~~
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] ActiveMapper : adding a DB column after a model change
I have defined a class like class Image(AciveMapper): class mapping: __table__ = "image" id = column(Integer, primary_key=True) url = column(Unicode(128)) and created the DB according to the model. I have modified the Image class to add a new column class Image(AciveMapper): class mapping: __table__ = "image" id = column(Integer, primary_key=True) url = column(Unicode(128)) mime_type = column(Unicode(32)) I can't find how to update the DB schema without dropping the table or going through SQL. Any help ?? --~--~-~--~~~---~--~~ 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: no error when using wrong 'attribute' name on an object
Michael Bayer a écrit :
well, theres nothing that says the attribute youre sending in is
"wrong". classes in python dont have any notion of predeclared
attribute names. a mapped class can have any number of other
attributes which dont correspond to database-mapped attributes.
Yes, of course. I was focused on the database...
in your case, you would like to constrain the attributes on your class
to the set of those which have been explicitly set up in a mapping
relationship. youd implement your own constructor like this:
class MyBaseClass(ActiveMapper):
def __init__(self, **kwargs):
mapper = class_mapper(self.__class__)
for key, value in kwargs.items():
if key not in mapper.props:
raise AttributeError("non mapped attribute: '%s'" %
key)
setattr(self, key, value)
class Color(MyBaseClass):
# etc
I'll try this approach. Thanks.
while im not a big ActiveMapper user, id leave it up to the
ActiveMapper developers if they think this behavior should be built in
to ActiveMapper itself (i kind of dont think it should be).
>
--~--~-~--~~~---~--~~
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] no error when using wrong 'attribute' name on an object
Hello, suppose I have the following definition : class Color(ActiveMapper): class mapping: __table__ = "color" id = column(Integer, primary_key=True) color = column(Unicode(32), unique=True) my problem is that if I do a typo when trying to create or modify a "color" like r = Color(colore='red') # notice the e at colore... or r. = 32 I get no error, so debugging is not easy at all ! Is there a way to get some messages when using wrong attributes ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
