[sqlalchemy] Polymorphic write - 'InstanceState' object has no attribute 'manager'
Hi, This trace is from some code that is loading a lot of objects (and which usually does so with no problems). I don't have more details yet (it will be quite some work to find out exactly what data is causing the error), but it does use joined table inheritance. Does anyone have any idea what the cause might be just from the trace? SQLAlchemy 0.5.8 with Python 2.5 on Linux. Thanks, Andrew File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/ manage/statio\ ns.py, line 170, in _zero loader.commit() File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/load/ loader.p\ y, line 169, in commit self.__load_data(entity_map, time_series_map, metric_map) File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/load/ loader.p\ y, line 291, in __load_data self.__session.flush() File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/sessi\ on.py, line 1354, in flush self._flush(objects) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/sessi\ on.py, line 1432, in _flush flush_context.execute() File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 261, in execute UOWExecutor().execute(self, tasks) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 753, in execute self.execute_save_steps(trans, task) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 768, in execute_save_steps self.save_objects(trans, task) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 759, in save_objects task.mapper._save_obj(task.polymorphic_tosave_objects, trans) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/mappe\ r.py, line 1434, in _save_obj if mapper._get_state_attr_by_column(state, col) is None and len(primary_key\ ) i: File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/mappe\ r.py, line , in _get_state_attr_by_column return self._get_col_to_prop(column).getattr(state, column) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/prope\ rties.py, line 99, in getattr return state.get_impl(self.key).get(state, state.dict) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/state\ .py, line 92, in get_impl return self.manager.get_impl(key) AttributeError: 'InstanceState' object has no attribute 'manager' -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Polymorphic write - 'InstanceState' object has no attribute 'manager'
this looks like some kind of serialization issue. are you deserializing instances before mappers have been compiled ?if you upgrade to 0.6, this will raise an error immediately at the point at which it occurs. On May 7, 2010, at 9:49 AM, andrew cooke wrote: Hi, This trace is from some code that is loading a lot of objects (and which usually does so with no problems). I don't have more details yet (it will be quite some work to find out exactly what data is causing the error), but it does use joined table inheritance. Does anyone have any idea what the cause might be just from the trace? SQLAlchemy 0.5.8 with Python 2.5 on Linux. Thanks, Andrew File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/ manage/statio\ ns.py, line 170, in _zero loader.commit() File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/load/ loader.p\ y, line 169, in commit self.__load_data(entity_map, time_series_map, metric_map) File /usr/local/home/andrewc/tngb3/repository-lib/src/kpi/load/load/ loader.p\ y, line 291, in __load_data self.__session.flush() File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/sessi\ on.py, line 1354, in flush self._flush(objects) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/sessi\ on.py, line 1432, in _flush flush_context.execute() File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 261, in execute UOWExecutor().execute(self, tasks) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 753, in execute self.execute_save_steps(trans, task) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 768, in execute_save_steps self.save_objects(trans, task) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/unito\ fwork.py, line 759, in save_objects task.mapper._save_obj(task.polymorphic_tosave_objects, trans) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/mappe\ r.py, line 1434, in _save_obj if mapper._get_state_attr_by_column(state, col) is None and len(primary_key\ ) i: File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/mappe\ r.py, line , in _get_state_attr_by_column return self._get_col_to_prop(column).getattr(state, column) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/prope\ rties.py, line 99, in getattr return state.get_impl(self.key).get(state, state.dict) File /usr/local/home/andrewc/SQLAlchemy-0.5.8/build/lib/sqlalchemy/ orm/state\ .py, line 92, in get_impl return self.manager.get_impl(key) AttributeError: 'InstanceState' object has no attribute 'manager' -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Polymorphic write - 'InstanceState' object has no attribute 'manager'
As far as I know, I'm doing nothing that complex. I am creating a pile of mapped objects in Python and then dumping them to the database. The most likely cause is that a field is None, or of the incorrect type in some way, I would have guessed. Andrew On May 7, 9:56 am, Michael Bayer mike...@zzzcomputing.com wrote: this looks like some kind of serialization issue. are you deserializing instances before mappers have been compiled ? if you upgrade to 0.6, this will raise an error immediately at the point at which it occurs. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Polymorphic write - 'InstanceState' object has no attribute 'manager'
manager is an attribute on InstanceState that is set at construction time, and is never changed thereafter.Looking at your error more closely, its not that manager is None, its not even present. That can only happen if something del'ed the manager attribute, the InstanceState somehow went through some failed deserialization process, or some gc-related activity had occurred involving that object. I'm not aware of any simple way to produce that effect. it certainly has nothing to do with the specifics of your mappings. On May 7, 2010, at 10:14 AM, andrew cooke wrote: As far as I know, I'm doing nothing that complex. I am creating a pile of mapped objects in Python and then dumping them to the database. The most likely cause is that a field is None, or of the incorrect type in some way, I would have guessed. Andrew On May 7, 9:56 am, Michael Bayer mike...@zzzcomputing.com wrote: this looks like some kind of serialization issue. are you deserializing instances before mappers have been compiled ?if you upgrade to 0.6, this will raise an error immediately at the point at which it occurs. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Problems with CachingQuery, query is performed but data is returned from cache
Hello, I'm having a strange problem with CachingQuery. I have a model that looks like this: User(object): . @classmethod def by_id(cls, id, cache=FromCache(default, by_id), invalidate=False): q = meta.Session.query(User).filter(User.id == id) if cache: q = q.options(cache) if invalidate: q.invalidate() return True return q.first() @classmethod def by_username(cls, username, cache=FromCache(default, by_username), invalidate=False): q = meta.Session.query(User).filter(User.username == username) if cache: q = q.options(cache) if invalidate: q.invalidate() return True return q.first() now unless i call User.by_id(id, invalidate=True), All my queries contain wrong cached data. even if i do directly in controller of my app something like: c.users = meta.Session.query(User).order_by(User.username).limit(30) the returned rows will have different values than in database. What is more funnier, i only invalidate cache if i invalidate with: User.by_id(id, invalidate=True), when in some other action i did User.by_username(username, invalidate=True), i saw the query performed to the database - which would mean that cache WAS invalidated, but returned data was still old cached one. And no its not template caching, ive performed all my tests inside controller. What else can be causing query to return wrong data ? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Two subclasses (single table inheritance) both requiring the same columns
Hi there, I have some (declarative, polymorphic) classes that use single-table inheritance. My configuration is similar to the below: class BasicObject(Base): col1 = Column(…) # discriminator, polymorphic setup etc class ObjectOne(BasicObject): col2 = Column(…) col3 = Column(…) class ObjectTwo(BasicObject): col2 = Column(…) # -- This is the same as col2 on ObjectOne col4 = Column(…) Previously, this worked fine in SA 0.5, but in 0.6 it raises an ArgumentError telling me it conflicts. For the moment, I have just moved these properties to the `BasicObject`, but that's not really where they should be. I have additional classes of `BasicObject` that shouldn't have that `col2` attribute. Is there a way I can get around this (and essentially declare them twice on the same table?). I know I could probably set them as different database columns and keep them as the same attribute on the mapper, but I really need the ability to query against that column across the different mappers (without having to do an OR). Is there a way around this? Any help would be appreciated :) Thanks, Oliver -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Two subclasses (single table inheritance) both requiring the same columns
On 05/07/2010 09:59 AM, Oliver Beattie wrote:
Hi there,
I have some (declarative, polymorphic) classes that use single-table
inheritance. My configuration is similar to the below:
class BasicObject(Base):
col1 = Column(…)
# discriminator, polymorphic setup etc
class ObjectOne(BasicObject):
col2 = Column(…)
col3 = Column(…)
class ObjectTwo(BasicObject):
col2 = Column(…) # -- This is the same as col2 on ObjectOne
col4 = Column(…)
Previously, this worked fine in SA 0.5, but in 0.6 it raises an
ArgumentError telling me it conflicts. For the moment, I have just
moved these properties to the `BasicObject`, but that's not really
where they should be. I have additional classes of `BasicObject` that
shouldn't have that `col2` attribute.
Is there a way I can get around this (and essentially declare them
twice on the same table?). I know I could probably set them as
different database columns and keep them as the same attribute on the
mapper, but I really need the ability to query against that column
across the different mappers (without having to do an OR). Is there a
way around this?
In this particular case, you can add an intermediate base class that
declares col2:
class BasicObject(Base):
col1 = Column(...)
class IntermediateBase(BasicObject):
col2 = Column(...)
class ObjectOne(IntermediateBase):
col3 = Column(...)
class ObjectTwo(IntermediateBase):
col4 = Column(...)
This approach fails when you have multiple columns to mix and match
between derived classes. The only way I have been able to do this is to
declare the table separately and selectively include ColumnPropertys
in each class:
basic_object = Table(
Column("col1", ...),
Column("col2", ...),
Column("col3", ...),
Column("col4", ...),
discriminator column, etc.)
base_props = ("col1", descriminator column, etc.)
class BasicObject(Base):
__table__ = basic_object
__mapper_args__ = {
"exclude_properties": None,
"include_properties": base_props,
...}
class ObjectOne(BasicObject):
__mapper_args__ = {
"exclude_properties": None,
"include_properties": base_props + ("col2", "col3"),
...}
class ObjectTwo(BasicObject):
__mapper_args__ = {
"exclude_properties": None,
"include_properties": base_props + ("col2", "col4"),
...}
I don't like the idea of "merging" two Column definitions
into a single column, because then you have to decide which Column
instance "wins", check for non-identical columns, etc. However, it
would be nice to allow declarative classes reference the same Column
instance multiple times, e.g.:
_col2 = Column("col2", ...)
class ObjectOne(BasicObject):
col2 = _col2
col3 = Column(...)
class ObjectTwo(BasicObject):
col2 = _col2
col3 = Column(...)
-Conor
--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalch...@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] PostgreSQL hstore custom type?
Thank you, I haven't started using hstore in my production environment yet, but wanted to do some tests with it as a way for users to attach arbitrary key/value metadata to nodes. Are you currently using a Gin or Gist index on your hstore columns? Yes, actually I've got a pretty good start on it. The only obvious thing missing right now is a Comparator implementation so that the custom hstore operations are available to mapped classes and not just to the SQL expression language. I did want to have access to hstore operations outside of mapped classes (i.e. just using SQL expression language) so I ended up implementing it slightly differently than I had originally thought. It required some hacks which I'm not sure how to do better. Some thoughts... 1. While you can override existing operators that work on ColumnElements without doing much funny business, if you want to add *new* operations to it, the abstractions leak fairly badly. This seems to be because operator definitions aren't delegated to the class representing the type, which is suboptimal because I would think that the type of a ColumnElement is what logically defines what operations are valid on it. The result of this is that I have to create classes like HStoreColumn, HStoreColumnElement, _HStoreDeleteFunction, and so on, so that SQL expressions which are logically of type 'hstore' will have the extended hstore operations available. 2. That expression operations on Foo.some_col and foo_table.c.some_col take completely different paths in the implementation was slightly surprising. I would have expected the former to be implemented in terms of the latter, so that SQL expressions available on some column type are automatically available on the descriptor of a class which maps to that column. But I don't know, there might be good reasons for this. In any case I'm trying to figure out how to write my Comparator for hstore without repeating myself a lot. Current implementation attached, with really hacky tests at the end :) Comments welcome. -Kyle -- David Gardner Pipeline Tools Programmer Jim Henson Creature Shop dgard...@creatureshop.com -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Problems with CachingQuery, query is performed but data is returned from cache
On May 7, 2010, at 10:44 AM, Ergo wrote: now unless i call User.by_id(id, invalidate=True), All my queries contain wrong cached data. even if i do directly in controller of my app something like: c.users = meta.Session.query(User).order_by(User.username).limit(30) the returned rows will have different values than in database. if you already loaded those User objects from a stale cache within the current transaction, then they'd still show that old data.If you want fresh from the current transaction you should expire those objects first. otherwise sounds like your cache is stale. from your example invalidate=True won't return any data whatsoever, so I'm assuming a regular call returns the correct result subsequent to an invalidate, so this isn't really indicating anything unusual. if you have strange things going on I'd suggest you use pdb to ensure data is as expected at each step. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
Hi, I do something like this to invalidate: --code-- User.by_id(id, invalidate=True) --code-- and on next request c.user = User.by_id(id) and no - regular query DOES NOT return right contents for me. c.users = meta.Session.query(User).order_by(User.username).limit(30) - this will only return right values if i explictly invalidate the cache - while i never nowhere cached this query with query cache. whats even more interesting: q = meta.Session.query(User).filter(User.id == id) - i have to invalidate THIS to get the query above working fine. Whats better, I invalidate the cache - and see the query executed against the database in console - i can see difference if i run invalidation or not. But even if i do see the query executed if i print the values the values are still fetched from cache. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
On May 7, 2010, at 12:41 PM, Ergo wrote: Hi, I do something like this to invalidate: --code-- User.by_id(id, invalidate=True) --code-- and on next request c.user = User.by_id(id) and no - regular query DOES NOT return right contents for me. c.users = meta.Session.query(User).order_by(User.username).limit(30) - this will only return right values if i explictly invalidate the cache - while i never nowhere cached this query with query cache. whats even more interesting: q = meta.Session.query(User).filter(User.id == id) - i have to invalidate THIS to get the query above working fine. Whats better, I invalidate the cache - and see the query executed against the database in console - i can see difference if i run invalidation or not. But even if i do see the query executed if i print the values the values are still fetched from cache. expire_all() your session. that is why you are seeing your stale cache data with a query that does not specify cache. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
On 7 Maj, 18:52, Michael Bayer mike...@zzzcomputing.com wrote: expire_all() your session. that is why you are seeing your stale cache data with a query that does not specify cache. Was that added recently ? this happens on subsequent requests in pylons application that in the end calls meta.Session.remove(). -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
On May 7, 2010, at 12:56 PM, Ergo wrote: On 7 Maj, 18:52, Michael Bayer mike...@zzzcomputing.com wrote: expire_all() your session. that is why you are seeing your stale cache data with a query that does not specify cache. Was that added recently ? this happens on subsequent requests in pylons application that in the end calls meta.Session.remove(). its been there for quite a long time. if you OTOH have called remove(), the next request uses a brand new session. if the request never specifies cache, then you're getting data from the DB transaction and assuming you're working in a transaction isolated context you'll always see just what the transaction sees. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
This is only happening when one uses QueryCache? Im completly lost now because back in 0.5.x i never saw a single problem of this kind. Every new request would use new correct data. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: [Distutils] inability to pass setup.py command line arguments to dependency setups
Just because there are configuration problems associated with adding a feature like the one I needed is absolutely no reason to abandon it when it can bring value to the tool if used correctly and in some circumstances. I considered some of those exact complications what if it was already installed, etc and with my company's project, where I am using this useful tool in a circumstance you may overlook (it is perfectly acceptable to have such a feature, *despite* the list of complications you mention), such a feature would have been very valuable. Since it is useful in my case, I understand it would be valuable for others as well. (I don't appreciate the aggressive tone of your reply, though, nor do I see how my good faith efforts to help others warrant this... how did I possibly offend you with my post??) On the other hand, I appreciate your correct solution as a good approach and I'll forward this idea to an author of SQLAlchemy for his consideration. On 5/7/2010 1:33 PM, Glyph Lefkowitz wrote: On May 7, 2010, at 9:09 AM, Kent wrote: Consider the case where you want your setup to install third-party software, but you want/need to pass an argument to the command line that runs python setup.py --argument install or python setup.py -- argument bdist_egg As far as I could research, this feature is unavailable. And for good reason, I should think. I really hope that nobody ever adds this feature. If you require SQLAlchemy to be installed --with-cextensions, then what happens when your package is installed in an environment that already has SQLAlchemy installed *without* that flag? Does it stomp on the existing installation? What if the user installed one already with that flag and some other flags as well? What if it's system-installed and you're doing a user-install? Basically, compile-time and install-time options are a configuration nightmare. They should represent only how and where a package is installed, not what features it has. The correct solution to your problem would be to get SQLAlchemy to fix its broken deployment setup and split itself into 2 packages, SQLAlchemyCExtensions and SQLAlchemy, and then have your project depend on both, not to try to cram installer options into the dependency language. For confirmation of this theory, you need look no further than the excruciating user-experience of source-based installation systems with 'variant' support, like gentoo's Portage and *BSD's Ports, versus the relatively non-excruciating experience of packaging systems which express compile-time options as different packages like Yum and Apt. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
the caching query example doesn't work with 0.5, so there's nothing to compare with 0.5. The workings of the identity map have not changed. On May 7, 2010, at 1:46 PM, Ergo wrote: This is only happening when one uses QueryCache? Im completly lost now because back in 0.5.x i never saw a single problem of this kind. Every new request would use new correct data. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: [Distutils] inability to pass setup.py command line arguments to dependency setups
I'd only mention that Storm has a C extension/non C extension flag as well, and only offers one source distribution on Pypi. You have to modify a variable directly within setup.py. Our setup.py features the same capability (its just our C extension is off by default for 0.6 since it was just written, which is the same case for when Storm first introduced its C extension). On May 7, 2010, at 1:56 PM, Kent Bower wrote: Just because there are configuration problems associated with adding a feature like the one I needed is absolutely no reason to abandon it when it can bring value to the tool if used correctly and in some circumstances. I considered some of those exact complications what if it was already installed, etc and with my company's project, where I am using this useful tool in a circumstance you may overlook (it is perfectly acceptable to have such a feature, *despite* the list of complications you mention), such a feature would have been very valuable. Since it is useful in my case, I understand it would be valuable for others as well. (I don't appreciate the aggressive tone of your reply, though, nor do I see how my good faith efforts to help others warrant this... how did I possibly offend you with my post??) On the other hand, I appreciate your correct solution as a good approach and I'll forward this idea to an author of SQLAlchemy for his consideration. On 5/7/2010 1:33 PM, Glyph Lefkowitz wrote: On May 7, 2010, at 9:09 AM, Kent wrote: Consider the case where you want your setup to install third-party software, but you want/need to pass an argument to the command line that runs python setup.py --argument install or python setup.py -- argument bdist_egg As far as I could research, this feature is unavailable. And for good reason, I should think. I really hope that nobody ever adds this feature. If you require SQLAlchemy to be installed --with-cextensions, then what happens when your package is installed in an environment that already has SQLAlchemy installed *without* that flag? Does it stomp on the existing installation? What if the user installed one already with that flag and some other flags as well? What if it's system-installed and you're doing a user-install? Basically, compile-time and install-time options are a configuration nightmare. They should represent only how and where a package is installed, not what features it has. The correct solution to your problem would be to get SQLAlchemy to fix its broken deployment setup and split itself into 2 packages, SQLAlchemyCExtensions and SQLAlchemy, and then have your project depend on both, not to try to cram installer options into the dependency language. For confirmation of this theory, you need look no further than the excruciating user-experience of source-based installation systems with 'variant' support, like gentoo's Portage and *BSD's Ports, versus the relatively non-excruciating experience of packaging systems which express compile-time options as different packages like Yum and Apt. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
Im lost and clueless maybe im completly dumb :( im trying really hard but i cant understand the problem. every request calls meta.Session.remove() at the end of request - i checked it does that. Now even when i do: meta.Session.query(User).order_by(User.username).limit(30) I see the query executed - but i get completly old data. I never had to do expire_all() in my pylons application before, im wondering if introduced some kind of problem to my application but im completly clueless about what could be possible case. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
what happens when you rip out all cache code entirely ? you ceratainly need to shut all of that off unconditionally before attempting to understand your issue. On May 7, 2010, at 2:17 PM, Ergo wrote: Im lost and clueless maybe im completly dumb :( im trying really hard but i cant understand the problem. every request calls meta.Session.remove() at the end of request - i checked it does that. Now even when i do: meta.Session.query(User).order_by(User.username).limit(30) I see the query executed - but i get completly old data. I never had to do expire_all() in my pylons application before, im wondering if introduced some kind of problem to my application but im completly clueless about what could be possible case. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
ok, i THINK i understand whats going on... i reproduced it and i think i understand whats going on since i was able to track the problem by restarting memcache and noticing that it gives me right values: its kinda deceiving at first, i do a request in application: lets assume we have a users table with rows A,B,C,D,E and in application i first do User.by_id(A) - which will cache or fetch cached object with beaker - user A is a logged user that is fetched every request, now lets say i go to some database frontend like pgadmin3 and change foo column for A,B,C,D,E. then for some report i do meta.Session.query(User).order_by(User.username).limit(30) to fetch all users. i get users B,C,D,E with new values of foo that i changed for them, but for user A on other hand foo has the value from the moment when i fetched him with by_id. So in my query results for some reason i got instance if User object A which i fetched earlier and got cached. Now i understand the problem, is this 100% expected behaviour ? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: Problems with CachingQuery, query is performed but data is returned from cache
it is 100% expected yes. its generally not a good idea to specify any caching for a particular entity type in a particular request where you expect to be getting fresh data from the DB for that entity type. On May 7, 2010, at 2:37 PM, Ergo wrote: ok, i THINK i understand whats going on... i reproduced it and i think i understand whats going on since i was able to track the problem by restarting memcache and noticing that it gives me right values: its kinda deceiving at first, i do a request in application: lets assume we have a users table with rows A,B,C,D,E and in application i first do User.by_id(A) - which will cache or fetch cached object with beaker - user A is a logged user that is fetched every request, now lets say i go to some database frontend like pgadmin3 and change foo column for A,B,C,D,E. then for some report i do meta.Session.query(User).order_by(User.username).limit(30) to fetch all users. i get users B,C,D,E with new values of foo that i changed for them, but for user A on other hand foo has the value from the moment when i fetched him with by_id. So in my query results for some reason i got instance if User object A which i fetched earlier and got cached. Now i understand the problem, is this 100% expected behaviour ? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: [Distutils] inability to pass setup.py command line arguments to dependency setups
Mike, Can I just take a second to thank you for your patience in running this forum? There are so many rude, arrogant software developers, and you seem to not be like them at all. Thanks. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: [Distutils] inability to pass setup.py command line arguments to dependency setups
FWIW, it is perfectly possible to package the thing separately as Glyph seem to suggest, even if the feature is enabled through an option. For example, Debian does it: http://packages.debian.org/experimental/python-sqlalchemy-ext On Fri, May 7, 2010 at 19:56, Kent Bower k...@retailarchitects.com wrote: Just because there are configuration problems associated with adding a feature like the one I needed is absolutely no reason to abandon it when it can bring value to the tool if used correctly and in some circumstances. I considered some of those exact complications what if it was already installed, etc and with my company's project, where I am using this useful tool in a circumstance you may overlook (it is perfectly acceptable to have such a feature, *despite* the list of complications you mention), such a feature would have been very valuable. Since it is useful in my case, I understand it would be valuable for others as well. (I don't appreciate the aggressive tone of your reply, though, nor do I see how my good faith efforts to help others warrant this... how did I possibly offend you with my post??) On the other hand, I appreciate your correct solution as a good approach and I'll forward this idea to an author of SQLAlchemy for his consideration. On 5/7/2010 1:33 PM, Glyph Lefkowitz wrote: On May 7, 2010, at 9:09 AM, Kent wrote: Consider the case where you want your setup to install third-party software, but you want/need to pass an argument to the command line that runs python setup.py --argument install or python setup.py -- argument bdist_egg As far as I could research, this feature is unavailable. And for good reason, I should think. I really hope that nobody ever adds this feature. If you require SQLAlchemy to be installed --with-cextensions, then what happens when your package is installed in an environment that already has SQLAlchemy installed *without* that flag? Does it stomp on the existing installation? What if the user installed one already with that flag and some other flags as well? What if it's system-installed and you're doing a user-install? Basically, compile-time and install-time options are a configuration nightmare. They should represent only how and where a package is installed, not what features it has. The correct solution to your problem would be to get SQLAlchemy to fix its broken deployment setup and split itself into 2 packages, SQLAlchemyCExtensions and SQLAlchemy, and then have your project depend on both, not to try to cram installer options into the dependency language. For confirmation of this theory, you need look no further than the excruciating user-experience of source-based installation systems with 'variant' support, like gentoo's Portage and *BSD's Ports, versus the relatively non-excruciating experience of packaging systems which express compile-time options as different packages like Yum and Apt. -- Gaëtan de Menten -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: [Distutils] [sqlalchemy] Re: inability to pass setup.py command line arguments to dependency setups
The build option for C extension or not is taken directly from the setup.py of Genshi, the template language, and as I said was also inspired by what Storm does in this regard. I think once we put the flag on by default there really won't be any controversy anymore - both of those packages build the C extension by default. It seems awkward that a source distribution (emphasis on the word source) would be broken up into two among configuration options (not to mention it would be totally inconvenient on my side). What if our build had six flags, not two - would I then provide SQLAlchemy as six separate downloads on Pypi ? e.g. the source distro of the Python Imaging Library has a whole set of flags you can set within setup.py to assist in its location of libraries - there's not much getting around those at the level of the source distro - a source distribution only represents the source code, not its particular configuration in a particular environment. You may say these are all broken configurations, but the simple fact is that we talking about a source distribution, not a dpkg or rpm. When you get PIL as a dpkg on your Ubuntu system, its pre-configured for the correct locations of libjpeg and such. Its a problem that is solved by those packaging libraries but is not solved by Python source distros on Pypi. The setuptools analogue to dpkg and rpm, I think, would be an .egg file.If someone wants to distrbute SQLAlchemy in some kind of package oriented system with pre-selected options, outside the realm of well known unix package managers, they can always package it as such. On May 7, 2010, at 2:58 PM, Gaetan de Menten wrote: FWIW, it is perfectly possible to package the thing separately as Glyph seem to suggest, even if the feature is enabled through an option. For example, Debian does it: http://packages.debian.org/experimental/python-sqlalchemy-ext On Fri, May 7, 2010 at 19:56, Kent Bower k...@retailarchitects.com wrote: Just because there are configuration problems associated with adding a feature like the one I needed is absolutely no reason to abandon it when it can bring value to the tool if used correctly and in some circumstances. I considered some of those exact complications what if it was already installed, etc and with my company's project, where I am using this useful tool in a circumstance you may overlook (it is perfectly acceptable to have such a feature, *despite* the list of complications you mention), such a feature would have been very valuable. Since it is useful in my case, I understand it would be valuable for others as well. (I don't appreciate the aggressive tone of your reply, though, nor do I see how my good faith efforts to help others warrant this... how did I possibly offend you with my post??) On the other hand, I appreciate your correct solution as a good approach and I'll forward this idea to an author of SQLAlchemy for his consideration. On 5/7/2010 1:33 PM, Glyph Lefkowitz wrote: On May 7, 2010, at 9:09 AM, Kent wrote: Consider the case where you want your setup to install third-party software, but you want/need to pass an argument to the command line that runs python setup.py --argument install or python setup.py -- argument bdist_egg As far as I could research, this feature is unavailable. And for good reason, I should think. I really hope that nobody ever adds this feature. If you require SQLAlchemy to be installed --with-cextensions, then what happens when your package is installed in an environment that already has SQLAlchemy installed *without* that flag? Does it stomp on the existing installation? What if the user installed one already with that flag and some other flags as well? What if it's system-installed and you're doing a user-install? Basically, compile-time and install-time options are a configuration nightmare. They should represent only how and where a package is installed, not what features it has. The correct solution to your problem would be to get SQLAlchemy to fix its broken deployment setup and split itself into 2 packages, SQLAlchemyCExtensions and SQLAlchemy, and then have your project depend on both, not to try to cram installer options into the dependency language. For confirmation of this theory, you need look no further than the excruciating user-experience of source-based installation systems with 'variant' support, like gentoo's Portage and *BSD's Ports, versus the relatively non-excruciating experience of packaging systems which express compile-time options as different packages like Yum and Apt. -- Gaëtan de Menten ___ Distutils-SIG maillist - distutils-...@python.org http://mail.python.org/mailman/listinfo/distutils-sig -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to
Re: [sqlalchemy] PostgreSQL hstore custom type?
On Fri, 7 May 2010 09:01:05 -0700 David Gardner dgard...@creatureshop.com wrote: Thank you, I haven't started using hstore in my production environment yet, but wanted to do some tests with it as a way for users to attach arbitrary key/value metadata to nodes. Are you currently using a Gin or Gist index on your hstore columns? This is basically what I'm doing with it, tracking arbitrary metadata-ish things on various objects, although at this point it's for internal use like flags and whatnot, but I expect it will extend to user supplied data as well, in the fullness of time. The application for which I wrote this is also not in production yet either, so experimenting with indexes would of course be futile right now. That said, I'm not sure what the practical difference is between choosing GiST or GiN on an hstore, they both support the same set of operators: contains (@), has key (?), and in 9.0 the new has all keys (?) and has any key (?|) operators. Speaking of which I should probably add support for the crap-ton of new hstore features that come out in 9.0: http://developer.postgresql.org/pgdocs/postgres/hstore.html FWIW, I do know that GiST support in PostGIS's geometry type is stupid fast. On a different project we're getting like 10-40msec query times to test for polygon intersection against a table of ~200k polygonal geographic objects on a dirt-cheap SATA dedibox, even which it picks up hundreds of matches. My expectations are high for hstore's index performance :) -Kyle -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
