Re: [sqlalchemy] Re: Order by in select doesn't seem to work
On Dec 27, 2011, at 10:37 AM, VDK wrote:
Michael,
I simplified my code just for test purposes. I'm now working with only
two columns, without order_by clause, commented a few other lines with
order by. I'm sure there is no order_by left in my code. I run the
script with echo set to debug. The result:
INFO:sqlalchemy.engine.base.Engine.0x...a7d0:{}
DEBUG:sqlalchemy.engine.base.Engine.0x...a7d0:Col
('contributie_alle_leden_id', 'contributie_alle_leden_achternaam')
2011-12-27 16:23:05,839 INFO sqlalchemy.engine.base.Engine.0x...a7d0
SELECT contributie_alle_leden.id AS contributie_alle_leden_id,
contributie_alle_leden.achternaam AS
contributie_alle_leden_achternaam
FROM (SELECT Leden.id AS id, Leden.achternaam AS achternaam
FROM Leden) AS contributie_alle_leden ORDER BY
contributie_alle_leden.id
The order by is still added. As sqlalchemy doesn't add things, the
only suspect now is elixir. This is part of the Camelot framework and
act as a layer upon SQLAlchemy.
*elixir* - I just searched your other emails and it appears they fail to
mention this extremely critical detail. Elixir adds default order_bys. You
need to use elixir's configuration flags to disable that.
I think this email thread is going to become the textbook example of why we
took out default order by, the next time someone asks.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: Order by in select doesn't seem to work
Michael,
I simplified my code just for test purposes. I'm now working with only
two columns, without order_by clause, commented a few other lines with
order by. I'm sure there is no order_by left in my code. I run the
script with echo set to debug. The result:
INFO:sqlalchemy.engine.base.Engine.0x...a7d0:{}
DEBUG:sqlalchemy.engine.base.Engine.0x...a7d0:Col
('contributie_alle_leden_id', 'contributie_alle_leden_achternaam')
2011-12-27 16:23:05,839 INFO sqlalchemy.engine.base.Engine.0x...a7d0
SELECT contributie_alle_leden.id AS contributie_alle_leden_id,
contributie_alle_leden.achternaam AS
contributie_alle_leden_achternaam
FROM (SELECT Leden.id AS id, Leden.achternaam AS achternaam
FROM Leden) AS contributie_alle_leden ORDER BY
contributie_alle_leden.id
The order by is still added. As sqlalchemy doesn't add things, the
only suspect now is elixir. This is part of the Camelot framework and
act as a layer upon SQLAlchemy.
Regards,
Peter
On Dec 25, 11:33 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Dec 25, 2011, at 3:19 PM, VDK wrote:
With echo=True, the following sql statements are reported:
INFO:sqlalchemy.engine.base.Engine.0x...9890:select version()
INFO:sqlalchemy.engine.base.Engine.0x...9890:{}
2011-12-25 21:08:58,796 INFO sqlalchemy.engine.base.Engine.0x...9890
select version()
2011-12-25 21:08:58,797 INFO sqlalchemy.engine.base.Engine.0x...9890
{}
INFO:sqlalchemy.engine.base.Engine.0x...9890:select current_schema()
INFO:sqlalchemy.engine.base.Engine.0x...9890:{}
2011-12-25 21:08:58,819 INFO sqlalchemy.engine.base.Engine.0x...9890
select current_schema()
2011-12-25 21:08:58,819 INFO sqlalchemy.engine.base.Engine.0x...9890
{}
2011-12-25 21:08:58,822 INFO sqlalchemy.engine.base.Engine.0x...9890
SELECT count(1) AS count_1
INFO:sqlalchemy.engine.base.Engine.0x...9890:SELECT count(1) AS
count_1
FROM (SELECT Leden.id AS id, Leden.achternaam AS achternaam,
Leden.tussenvoegsel AS tussenvoegsel, Leden.voorletters AS
voorletters, Leden.adres AS adres, Leden.postcode AS postcode,
Leden.woonplaats AS woonplaats, Tarieven.omschrijving AS
omschrijving, Tarieven.tariefbedrag AS tariefbedrag,
Leden.adresenpc AS adresenpc
FROM Leden, Tarieven
FROM (SELECT Leden.id AS id, Leden.achternaam AS achternaam,
Leden.tussenvoegsel AS tussenvoegsel, Leden.voorletters AS
voorletters, Leden.adres AS adres, Leden.postcode AS postcode,
Leden.woonplaats AS woonplaats, Tarieven.omschrijving AS
omschrijving, Tarieven.tariefbedrag AS tariefbedrag,
Leden.adresenpc AS adresenpc
WHERE Leden.lidsoort_id IN (%(lidsoort_id_1)s, %(lidsoort_id_2)s)
AND Tarieven.id = Leden.lidsoort_id ORDER BY Leden.achternaam)
AS contributie_alle_leden
FROM Leden, Tarieven
2011-12-25 21:08:58,822 INFO sqlalchemy.engine.base.Engine.0x...9890
{'lidsoort_id_2': 2, 'lidsoort_id_1': 1}
WHERE Leden.lidsoort_id IN (%(lidsoort_id_1)s, %(lidsoort_id_2)s)
AND Tarieven.id = Leden.lidsoort_id ORDER BY Leden.achternaam)
AS contributie_alle_leden
INFO:sqlalchemy.engine.base.Engine.0x...9890:{'lidsoort_id_2': 2,
'lidsoort_id_1': 1}
INFO:sqlalchemy.engine.base.Engine.0x...9890:SELECT
contributie_alle_leden.id AS contributie_alle_leden_id,
contributie_alle_leden.achternaam AS
contributie_alle_leden_achternaam,
contributie_alle_leden.tussenvoegsel AS
contributie_alle_leden_tussenvoegsel,
contributie_alle_leden.voorletters AS
contributie_alle_leden_voorletters, contributie_alle_leden.adres AS
contributie_alle_leden_adres, contributie_alle_leden.postcode AS
contributie_alle_leden_postcode, contributie_alle_leden.woonplaats AS
contributie_alle_leden_woonplaats, contributie_alle_leden.omschrijving
AS contributie_alle_leden_omschrijving,
contributie_alle_leden.tariefbedrag AS
contributie_alle_leden_tariefbedrag, contributie_alle_leden.adresenpc
AS contributie_alle_leden_adresenpc
2011-12-25 21:08:58,925 INFO sqlalchemy.engine.base.Engine.0x...9890
SELECT contributie_alle_leden.id AS contributie_alle_leden_id,
contributie_alle_leden.achternaam AS
contributie_alle_leden_achternaam,
contributie_alle_leden.tussenvoegsel AS
contributie_alle_leden_tussenvoegsel,
contributie_alle_leden.voorletters AS
contributie_alle_leden_voorletters, contributie_alle_leden.adres AS
contributie_alle_leden_adres, contributie_alle_leden.postcode AS
contributie_alle_leden_postcode, contributie_alle_leden.woonplaats AS
contributie_alle_leden_woonplaats, contributie_alle_leden.omschrijving
AS contributie_alle_leden_omschrijving,
contributie_alle_leden.tariefbedrag AS
contributie_alle_leden_tariefbedrag, contributie_alle_leden.adresenpc
AS contributie_alle_leden_adresenpc
FROM (SELECT Leden.id AS id, Leden.achternaam AS achternaam,
Leden.tussenvoegsel AS tussenvoegsel, Leden.voorletters AS
voorletters, Leden.adres AS adres, Leden.postcode AS postcode,
Leden.woonplaats AS woonplaats, Tarieven.omschrijving AS
omschrijving,
Re: [sqlalchemy] Pickle/beaker error with InstrumentedList
Thanks for the code, your example runs without a problem. I've managed to locate the error. In reality it doesn't have to do with InstrumentedList. The problem occurs when beaker pickle.load()s from its cache file (a pickled object in a file). I get the following exception (which makes beaker stop loading the session): AttributeError: 'User' object has no attribute '_sa_instance_state' If I try to load the file directly I get the same result. I've been trying to google such error but all I get the reference to is that orm.mapper() should be run in the thread or process that is loading the pickled object. I tried loading manually (in a python console) my mappers and the trying to unpickle the object without success. I cannot (at the moment) include a code example because it is a medium sized pylons project. I know that this was working with version 0.6, with orm.synonym; the main difference is that now I use @hybrid_property and version 0.7.4. I will try to make a small project and try to reproduce the error, but if you have any idea of why is doing this I will appreciate it if you can lead me to a possible solution. Thanks. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/Em-Xaxb5QFUJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Pickle/beaker error with InstrumentedList
On Dec 27, 2011, at 4:54 AM, Arturo Sevilla wrote: Thanks for the code, your example runs without a problem. I've managed to locate the error. In reality it doesn't have to do with InstrumentedList. The problem occurs when beaker pickle.load()s from its cache file (a pickled object in a file). I get the following exception (which makes beaker stop loading the session): AttributeError: 'User' object has no attribute '_sa_instance_state' That means User wasn't mapped when the object was created. This is one of many reasons I've been encouraging declarative as the standard way to go these days, so that you can't create a class without it being mapped at once. If I try to load the file directly I get the same result. I've been trying to google such error but all I get the reference to is that orm.mapper() should be run in the thread or process that is loading the pickled object. I tried loading manually (in a python console) my mappers and the trying to unpickle the object without success. mapper() needs to be run in the process, and should be run in the main thread before any worker threads are spawned. It should ideally be part of module import, or at the very least a right after import initialization step. The User object itself must be mapped before the original one is ever created, before it is ever pickled in the first place. If it doesn't have a state, it means it was not mapped when pickled. I cannot (at the moment) include a code example because it is a medium sized pylons project. I know that this was working with version 0.6, with orm.synonym; the main difference is that now I use @hybrid_property and version 0.7.4. I can't think of a way that @synonym by itself would affect this. Changing back to @synonym in 0.7.4 does what ? -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: 0.7 event migration
On Dec 26, 5:12 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Dec 26, 2011, at 1:50 PM, Kent wrote: Yes, a nice simplification. I'm using it to lazyload attributes for objects that aren't in a session. I'm not sure if you pointed me there, I think I found it myself, but you helped work out the later details... Our app lives inside a webserver framework that, very appropriately, in my opinion, only has one session for any given web request. So, for our framework, I can safely lazyload related attributes for transient or detached objects by temporarily setting state.session_id: heh yes this is exactly what things used to do between like version 0.2 and 0.4 :) - if there was no session, it would look in the threadlocal context which somehow was associated with things. This was one of many implicit decisions/surprises we took out in favor of a behavioral model that's transparent. For awhile there we also had this crazy session lookup logic that was quasi-optional, nobody knew what it was, and I had similar endless threads with a few interested folks like yourself trying to explain/rationalize it, as well as try to decide how this could be an optional hook. The library only improved as I took out all kinds of tricks like this which were leftovers from the original 0.1 model that followed the magic everything, everywhere pattern. various things come to mind in terms of re-enabling this pattern. One is that the session registry would be extensible. Technically it is right now if you were to override orm.session._state_session(). Then the lazyloaders would treat the parent object as though it were inside of whatever session you had it returning here. You could even hardwire it to the contextual session itself - then even sharing objects among threads would be selecting the current thread's session. I could barely consider what level of surprise side effects might/might not occur from this practice, but it is how things used to work. If you want to play with it, I can re-add some kind of event for this. I have a name like detached session in my mind, maybe an event that's only called if there's no session_id, maybe it's just a session registry you stick onto a mapper, though I suppose the event hook is a good place here. The other is that the loader callable here is a lot like an event and we could put a hook here that you'd just listen() for. That wouldn't be very difficult to do, though determining when it's invoked would be tricky. When the value is locally present in __dict__, I wouldn't want even one function call of latency there checking for a possible event handler. When the value isn't present, would the event be before callable_() is invoked, or only if callable_() is not present, etc. Also i played around with how the load_lazy function could be exposed such that the Session could be supplied, but it's not very nice for a public API - some loader callables populate the attribute, others return the function and the AttributeImpl does the population. Exposing this publicly would mean I can't adjust that without the risk of breaking existing apps. So see what happens if you, for the moment, just monkeypatch over orm.session._state_session to do a lookup in a global context if state.session_id isn't set. If that solves the problem of I want detached objects to load stuff, for you and everyone else who wants this feature, then whatever - I'm not at all thrilled about this use case but if it's just one trivial hook that I don't need to encourage, then there you go. Sounds good, I'll look into that. But I'm curious why this approach is preferable over the one I've currently got (callable_ seems more public than _state_session). I admit, it would free my code from the passive logic, since I know you were considering changing those to bit flags, but why is this callable_ approach bad? def configure_attribute(class_, attr, inst): Set up function to be invoked when relations are 'get'ed on possibly transient objects, so we can automatically query these related objects if isinstance(inst.property, RelationshipProperty): default_loader = inst.impl.callable_ def load_value(state, passive): if state.session_id is not None: # this is persistent or pending, so # return default sqla functionality return default_loader(state, passive) if passive is attributes.PASSIVE_NO_FETCH: return attributes.PASSIVE_NO_RESULT # session_id is currently None state.session_id = DBSession().hash_key retval = default_loader(state, passive) state.session_id = None return retval inst.impl.callable_ = load_value .. .. event.listen(DBEntity, 'attribute_instrument',
Re: [sqlalchemy] Re: 0.7 event migration
On Dec 27, 2011, at 8:10 AM, Kent wrote: Sounds good, I'll look into that. But I'm curious why this approach is preferable over the one I've currently got (callable_ seems more public than _state_session). callable_ does not accept the session as an argument, and while I looked into ways of exposing a similar callable_ that does accept a Session, it didn't produce a feature that would make much sense to people, nor of be much use; the only need to get at the callable_ is to enable the hack you have here, which is entirely so that lazy loaders work on detached objects. Alternatively, there's already a well known behavior that we used to have up until version 0.4, which is to link the master session registry with an arbitrary contextual one, which we can quietly re-enable. Having you test this with the non-public _state_session is just a proof of concept. I admit, it would free my code from the passive logic, since I know you were considering changing those to bit flags, but why is this callable_ approach bad? this is essentially the pattern: def do_something(object): my_important_thing = object.my_important_thing if not my_important_thing: raise Exception(Object doesn't have my important thing!) myobject = get_some_object() important_thing = get_some_important_thing() myobject.my_important_thing = important_thing do_something(object) myobject.my_important_thing = None We'd prefer to just pass two arguments: def do_something(object, my_important_thing): # ... myobject = get_some_object() important_thing = get_some_important_thing() do_something(myobject, important_thing) That way we aren't mutating state, which is never preferred, and we allow the signature of do_something() to ensure the correct state instead of resorting to manual extraction and argument checking.Your current approach is a hack because it makes it obvious that the public API was not designed for what you're doing and then resorts to state mutation in order to pass an argument. At another level, it also exposes the mechanics of attribute lazy loading inside your application. It's simpler on your end for these details to not be necessary. Within SQLAlchemy, our methods DeferredLoader._load_for_state and LazyLoader._load_for_state are fixed to a specific use case, where we assume session is on the object and it's an error otherwise, then as a second step we do a loading operation with this session. For the API change I tried, part of it involves breaking out the second half of each _load_for_state into a method like def _lazy_load(self, session, state, passive), so that the validation rule of extract session and ensure it's present and the operation of load something are separate. As SQLA itself doesn't need _lazy_load() separately right now it's not necessary and we have a more coarse grained method, but if we wanted to expose the callable_() in a more open ended way this would be part of the change. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] declarative and late reflection?
Cool -- works nicely, thanks again! On Fri, Dec 23, 2011 at 2:56 AM, Michael Bayer mike...@zzzcomputing.comwrote: On Dec 22, 2011, at 7:28 PM, Michael Bayer wrote: this could work really nicely with extend_existing, which has been enhanced in 0.7.4, but there seem to be some glitches preventing it from being super nice, so I can't get that to work right now. Just send in those columns via your own means: Those glitches have a pending patch in ticket 2356: http://www.sqlalchemy.org/trac/ticket/2356 See the modified example case there. In 0.7.5 your use case will work exactly as you intend, where you'll be able to add Column objects to your declared class that will take precedence over what's autoloaded. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- http://sabaini.at -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] SAWarning: Object of type Discount not in session, add operation along 'OrderDetailDiscount.discount' won't proceed
In http://www.sqlalchemy.org/trac/changeset/7025%3A0a6576abea5b#file1 you added a warning that I'm hitting now. 'when save-update cascade is disabled, or the target object is otherwise not present in the session, and collection/scalar changes have taken place. A warning is emitted describing the type of operation, the target reference, and the relationship description, stating that the operation will not take place.' Do you think it is appropriate to skip the warning if the object isn't in the session *and* the save-update cascade is disabled? With *both* conditions present, it would seem the user has arranged them as such intentionally (at least in my case). Either that or they messed up twice (I suppose that is the more conservative approach, huh?) Possibly consider a different warning for that case? I like the idea of raising this warning, but only if one or the other conditions exist, but not both. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SAWarning: Object of type Discount not in session, add operation along 'OrderDetailDiscount.discount' won't proceed
On Dec 27, 2011, at 1:51 PM, Kent wrote: In http://www.sqlalchemy.org/trac/changeset/7025%3A0a6576abea5b#file1 you added a warning that I'm hitting now. 'when save-update cascade is disabled, or the target object is otherwise not present in the session, and collection/scalar changes have taken place. A warning is emitted describing the type of operation, the target reference, and the relationship description, stating that the operation will not take place.' Do you think it is appropriate to skip the warning if the object isn't in the session *and* the save-update cascade is disabled? With *both* conditions present, it would seem the user has arranged them as such intentionally (at least in my case). It basically means it's doing a flush and outright ignoring an object that you've assigned to a collection or scalar. I don't know that the UOW should ever break it's behavioral contract that badly and not at least say something. Either that or they messed up twice (I suppose that is the more conservative approach, huh?) The save-update cascade is often disabled so that someone can have control over when an object gets placed into the session.In that case they want to still be adding objects in manually, so actually when save-update is turned off is when the warning does actually become very important. Possibly consider a different warning for that case? I like the idea of raising this warning, but only if one or the other conditions exist, but not both. so you're not only working with detached objects, getting them to load things despite their being detached, which I've maintained is not how the ORM was intended to be used, now you're also trying to mix and match them with collections that are being flushed ?Can I get a reminder what the use case here is again ? I hope this isn't all just for performance -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] money type for Postgresql
Quick hack, figured I would share since there seemed to be other people asking about it. I couldn't get it to work with autoload=True for table reflection. --- from sqlalchemy import types from decimal import Decimal class Money(types.UserDefinedType): def get_col_spec(self): return 'money' def result_processor(self, dialect, coltype): def process(value): # Strip off the currency symbol return Decimal(value[1:]) return process -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SAWarning: Object of type Discount not in session, add operation along 'OrderDetailDiscount.discount' won't proceed
On 12/27/2011 2:34 PM, Michael Bayer wrote: On Dec 27, 2011, at 1:51 PM, Kent wrote: In http://www.sqlalchemy.org/trac/changeset/7025%3A0a6576abea5b#file1 you added a warning that I'm hitting now. 'when save-update cascade is disabled, or the target object is otherwise not present in the session, and collection/scalar changes have taken place. A warning is emitted describing the type of operation, the target reference, and the relationship description, stating that the operation will not take place.' Do you think it is appropriate to skip the warning if the object isn't in the session *and* the save-update cascade is disabled? With *both* conditions present, it would seem the user has arranged them as such intentionally (at least in my case). It basically means it's doing a flush and outright ignoring an object that you've assigned to a collection or scalar. I don't know that the UOW should ever break it's behavioral contract that badly and not at least say something. Either that or they messed up twice (I suppose that is the more conservative approach, huh?) The save-update cascade is often disabled so that someone can have control over when an object gets placed into the session.In that case they want to still be adding objects in manually, so actually when save-update is turned off is when the warning does actually become very important. Possibly consider a different warning for that case? I like the idea of raising this warning, but only if one or the other conditions exist, but not both. so you're not only working with detached objects, getting them to load things despite their being detached, which I've maintained is not how the ORM was intended to be used, now you're also trying to mix and match them with collections that are being flushed ?Can I get a reminder what the use case here is again ? I hope this isn't all just for performance Haha! I sense you're getting irritated, Mike! It's got little to do with performance... it's more a serialization artifact. To keep our web server truly stateless (well, 99.9% stateless), our objects are stored in memory client side until the user clicks save, then they are serialized and sent to python, deserialized, turned into transient sa objects and merged into the session. There are certain objects that aren't placed in the session because they aren't in the merge cascade (purposefully). These are transient objects I think that's where I'm hitting this warning. It's been working quite well for about a year since we've been live. We've a lot of work to do (oracle 8 and all), and sqlalchemy is beautiful toolset to make it work. It's a toolset to build an orm, right? Not necessarily an orm out of the box to fit every need. So don't be offended when I hack at it a bit (trust me, I try to work within the public API as it was intended to be used, and I'm the only one in the company who it goes against my grain to hack... the other guys would have trashed it by now! I'm the one on your side, believe it or not! ;) I don't mind if you don't want to change the warnings, just wanted your input whether it made sense. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] money type for Postgresql
don't use the MONEY type in PostgreSQL, use NUMERIC instead. On 12/27/2011 20:39, dgardner wrote: Quick hack, figured I would share since there seemed to be other people asking about it. I couldn't get it to work with autoload=True for table reflection. --- from sqlalchemy import types from decimal import Decimal class Money(types.UserDefinedType): def get_col_spec(self): return 'money' def result_processor(self, dialect, coltype): def process(value): # Strip off the currency symbol return Decimal(value[1:]) return process -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SAWarning: Object of type Discount not in session, add operation along 'OrderDetailDiscount.discount' won't proceed
On Dec 27, 2011, at 3:33 PM, Kent wrote: Haha! I sense you're getting irritated, Mike! oops...that should never show... There are certain objects that aren't placed in the session because they aren't in the merge cascade (purposefully). These are transient objects I think that's where I'm hitting this warning. do you need the transient objects to be present in collections/attributes owned by pending/persistent objects ? It's a toolset to build an orm, right? OK, yes. If you're building on .orm and not just the core, you get a certain behavioral model that you're building on top of. The behavioral model is built around everything being in a Session, with a transaction going on, and if its not in a Session that means it's essentially in transit from one Session to another.That seems like mostly what you're doing here. Not necessarily an orm out of the box to fit every need. So don't be offended when I hack at it a bit (trust me, I try to work within the public API as it was intended to be used, and I'm the only one in the company who it goes against my grain to hack... the other guys would have trashed it by now! I'm the one on your side, believe it or not! ;) yes absolutely !I'm just stressed when challenged to make small modifications without really understanding the bigger need. I don't mind if you don't want to change the warnings, just wanted your input whether it made sense. based on the current model it makes sense. A partially detached model that knows not to warn in some cases would require a lot more thought. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: 0.7 event migration
So see what happens if you, for the moment, just monkeypatch over orm.session._state_session to do a lookup in a global context if state.session_id isn't set. If that solves the problem of I want detached objects to load stuff, for you and everyone else who wants this feature, then whatever - I'm not at all thrilled about this use case but if it's just one trivial hook that I don't need to encourage, then there you go. Please give me a lesson in monkeypatching 101. This isn't being invoked: = import sqlalchemy.orm.session as session_module sqla_state_session = session_module._state_session def _state_session(state): for transient/detached objects, so we can automatically query these related objects return sqla_state_session(state) or DBSession() setattr(session_module, '_state_session', _state_session) = I presume there are already references to _state_session before I change it. Also, will this cause other side effects, such as obj in DBSession reporting True when it used to report False or the orm internals being confused by the return of this value? Thanks again! -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: 0.7 event migration
On Dec 27, 2011, at 5:21 PM, Kent wrote: So see what happens if you, for the moment, just monkeypatch over orm.session._state_session to do a lookup in a global context if state.session_id isn't set. If that solves the problem of I want detached objects to load stuff, for you and everyone else who wants this feature, then whatever - I'm not at all thrilled about this use case but if it's just one trivial hook that I don't need to encourage, then there you go. Please give me a lesson in monkeypatching 101. This isn't being invoked: = import sqlalchemy.orm.session as session_module sqla_state_session = session_module._state_session def _state_session(state): for transient/detached objects, so we can automatically query these related objects return sqla_state_session(state) or DBSession() setattr(session_module, '_state_session', _state_session) = I presume there are already references to _state_session before I change it. Hm I would have guessed, but mapper.py and strategies.py seem to be calling it relative to the module. What does pdb tell you if you post mortem into where it raises the Detached error ? Also, will this cause other side effects, such as obj in DBSession reporting True when it used to report False or the orm internals being confused by the return of this value? maybe ? if it doesn't just work then yes. The new logic here only needs to take place at the point at which it loads an attribute so if we made it local to those areas, there shouldn't be any big issues. I'm basically making you a developer here to help me test this out. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Order by the sequence in_ ?
Hi all. I need to select some rows where pkey is in a sequence. How do I order by that very sequence? images_all = session.query(AdImage).filter(AdImage.image_id.in_(images)).order_by( ? ).all() Postgresql backend. Thanks! -- .oO V Oo. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: money type for Postgresql
While there may be legitimate reasons to choose the numeric type instead of the money type. This might not always be an option for people, especially when working with existing database. If a type is supported by a database back end there is no reason why it couldn't and shouldn't be supported by SQLAlchemy, especially when features like TypeDecorators and compiler extensions make doing so easy. On Dec 27, 1:01 pm, Julien Cigar jci...@ulb.ac.be wrote: don't use the MONEY type in PostgreSQL, use NUMERIC instead. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
