[sqlalchemy] Re: changing instance identity
Michael Bayer ha scritto: that is your own application changing the primary key of a loaded instance, which is a feature very old versions of SQLAlchemy did not support. Upgrade to any recent version of 0.4 or 0.5 and you wont have that issue anymore. I think I don't want to change this behavior , Michael, Simply I would like to realize that changes was done at current loaded instance to avoid flush it. Here another similar error when I try to flush an instance already flushed... File /usr/lib/python2.4/site-packages/sqlalchemy/ext/assignmapper.py, line 7, in do return getattr(query, name)(*args, **kwargs) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/query.py, line 114, in get key = self.mapper.identity_key(ident) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/mapper.py, line 992, in identity_key return self.identity_key_from_primary_key(primary_key) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/mapper.py, line 959, in identity_key_from_primary_key return (self.class_, tuple(util.to_list(primary_key)), self.entity_name) TypeError: iteration over non-sequence Is there any property in the instance to see its state before flushing it? j On May 20, 2009, at 1:45 AM, jo wrote: Hello all, I have the following problem. While I'm working in my session, someone change my instance identity. I would like to avoid this. Is there a way to understand if was there any change before flushing? This is the message: File /usr/lib/python2.4/site-packages/sqlalchemy/orm/mapper.py, line 1078, in save_obj raise exceptions.FlushError(Can't change the identity of instance %s in session (existing identity: %s; new identity: %s) % (mapperutil.instance_str(obj), obj._instance_key, instance_key)) FlushError: Can't change the identity of instance spe...@0x5cc4590 in session (existing identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'0141',), None); new identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'08',), None)) thank you for any help 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: how to transaction like this
thanks very much! On 5月20日, 下午9时03分, Werner F. Bruhin werner.bru...@free.fr wrote: Hi, manman wrote: yes,i known,but how do i do that? if not commit parent,how to get the parent id? flush should be enough, but I think you could also do: assuming you have a relation parent c.parent.append(p) or the other way round p.children.append(c) Werner --~--~-~--~~~---~--~~ 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: changing instance identity
jo ha scritto: Michael Bayer ha scritto: that is your own application changing the primary key of a loaded instance, which is a feature very old versions of SQLAlchemy did not support. Upgrade to any recent version of 0.4 or 0.5 and you wont have that issue anymore. I think I don't want to change this behavior , Michael, Simply I would like to realize that changes was done at current loaded instance to avoid flush it. cut Yes you have it, cls._state['original'].data but probably you must work over object stored in session Gla --~--~-~--~~~---~--~~ 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: changing instance identity
Glauco wrote: jo ha scritto: Michael Bayer ha scritto: that is your own application changing the primary key of a loaded instance, which is a feature very old versions of SQLAlchemy did not support. Upgrade to any recent version of 0.4 or 0.5 and you wont have that issue anymore. I think I don't want to change this behavior , Michael, Simply I would like to realize that changes was done at current loaded instance to avoid flush it. cut Yes you have it, cls._state['original'].data but probably you must work over object stored in session Gla cls._state['original'].data returns the instance data. What I need instead is how to retrieve the value of 'existing identity' and 'new identity' to compare them before sa raises the exception FlushError. Something like: if obj._instance_key instance_key: do_not_flush to avoid the following error: raise exceptions.FlushError(Can't change the identity of instance %s in session (existing identity: %s; new identity: %s) % (mapperutil.instance_str(obj), obj._instance_key, instance_key)) FlushError: Can't change the identity of instance spe...@0xa6e046c in session (existing identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'0141',), None); new identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'08',), None)) --~--~-~--~~~---~--~~ 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: changing instance identity
On May 21, 2009, at 2:04 AM, jo wrote: Michael Bayer ha scritto: that is your own application changing the primary key of a loaded instance, which is a feature very old versions of SQLAlchemy did not support. Upgrade to any recent version of 0.4 or 0.5 and you wont have that issue anymore. Is there any property in the instance to see its state before flushing it? here are the ways to check for changes, if thats what it is you're looking for. Most of them will still require that you upgrade from your very old version of SQLAlchemy: obj in session.dirty session.is_modified(obj) from sqlalchemy.orm import attributes history = attributes.get_history(obj, attrname) --~--~-~--~~~---~--~~ 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: changing instance identity
Michael Bayer wrote: On May 21, 2009, at 2:04 AM, jo wrote: Michael Bayer ha scritto: that is your own application changing the primary key of a loaded instance, which is a feature very old versions of SQLAlchemy did not support. Upgrade to any recent version of 0.4 or 0.5 and you wont have that issue anymore. Is there any property in the instance to see its state before flushing it? here are the ways to check for changes, if thats what it is you're looking for. Most of them will still require that you upgrade from your very old version of SQLAlchemy: obj in session.dirty session.is_modified(obj) from sqlalchemy.orm import attributes history = attributes.get_history(obj, attrname) I see, Michael, you are right, I need to upgrade my SQLAlchemy version. In the meanwhile I did a last try, to trap the FlushError exception. raise exceptions.FlushError(Can't change the identity of instance %s in session (existing identity: %s; new identity: %s) % (mapperutil.instance_str(obj), obj._instance_key, instance_key)) FlushError: Can't change the identity of instance spe...@0x9f4b9ac in session (existing identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'0141',), None); new identity: (class 'sicer.BASE.model.tabelleCodifica.specie.Specie', (u'08',), None)) in this way: from sqlalchemy.exceptions import FlushError try: session.flush() except FlushError: session.expunge(obj) ... but, it seems an error from TG. What exactly do session.expunge ? Page handler: bound method Controller.save of sicer.BASE.controller.tabelleCodifica.specie.Controller instance at 0x9e9f30c Traceback (most recent call last): File /var/lib/python-support/python2.4/cherrypy/_cphttptools.py, line 105, in _run self.main() File /var/lib/python-support/python2.4/cherrypy/_cphttptools.py, line 254, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in save File /usr/lib/python2.4/site-packages/TurboGears-1.0.3.2-py2.4.egg/turbogears/identity/conditions.py, line 235, in require return fn(self, *args, **kwargs) File string, line 3, in save File /usr/lib/python2.4/site-packages/TurboGears-1.0.3.2-py2.4.egg/turbogears/controllers.py, line 342, in expose output = database.run_with_transaction( File string, line 5, in run_with_transaction File /usr/lib/python2.4/site-packages/TurboGears-1.0.3.2-py2.4.egg/turbogears/database.py, line 362, in sa_rwt retval = dispatch_exception(e,args,kw) File /usr/lib/python2.4/site-packages/TurboGears-1.0.3.2-py2.4.egg/turbogears/database.py, line 360, in sa_rwt req.sa_transaction.commit() File /usr/lib/python2.4/site-packages/sqlalchemy/orm/session.py, line 73, in commit t[1].commit() File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py, line 670, in commit raise exceptions.InvalidRequestError(This transaction is inactive) InvalidRequestError: This transaction is inactive 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: changing instance identity
On May 21, 2009, at 10:56 AM, jo wrote: ... but, it seems an error from TG. What exactly do session.expunge ? expunge is described at: http://www.sqlalchemy.org/docs/05/session.html#expunging --~--~-~--~~~---~--~~ 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: 5.2 to 5.3 base-class/sub-class handling change
Thanks. I was trying to map both classes to the same table, and that was causing problems! On Apr 10, 1:43 pm, Michael Bayer mike...@zzzcomputing.com wrote: limscoderwrote: In 5.2 I was able to map a base-class, and sub-classes would automatically be persisted as the base type. In 5.3 I get an UnmappedInstanceError when trying to persist an object of the sub- class type. I didn't see anything about this change in the changelog. Is there a way to get the 5.3 behavior? this behavior isn't supported since if you said: class MySubClass(MyMappedClass): def __init__(self): self.foo = 'foo' the class no longer has the proper instrumentation on the __init__ method. the solution is to map your subclass. this is automatic if you use declarative. in any case, no table is needed: mapper(MySubClass, inherits=MyMappedClass) --~--~-~--~~~---~--~~ 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] Small note on reading SA docs
Hi. Currently, the documentation for SA is not easy for the eyes. Using http://www.sqlalchemy.org/docs/04/sqlalchemy_engine.html as an example, there are ways to improve this: * Quasi syntax highlighting the function and it's arguments. Having def create(self, entity, **kwargs) all in bold is making it hard to browse through the functions by name as, at least, I often do. I also takes some effort separating the arguments from each other. For instance, close_with_result=False is also all in bold. False should undoubtedly be of a different format than the argument name. * Differentiate class documentation from function documentation. Today, the class header is just ~2px larger than the function header, i.e., not a big enough deviation. Using 30%+ larger header or wrapping it in a styled box should do it. * De-emphasizing back to section top. The link is almost the same size as the class ancestor (constructor argument), which requires effort to separate. * The darkcell div is indeed superfluous. One could create the same effect of division with white space and/or horizontal bordering. * Emphasizing class properties and module includes. The default indentation of definition data is not sufficient. * Generally using white space more efficiently. I could happily assist someone in charge of the site, or do it myself. For the latter, I probably need some approval, branches of both sqlalchemy and sqlalchemyorg repos, or both? Anyway, SA is an impressive project. Kind regards, Jonas. --~--~-~--~~~---~--~~ 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: Small note on reading SA docs
On May 21, 2009, at 7:14 PM, semafor wrote: Hi. Currently, the documentation for SA is not easy for the eyes. Using http://www.sqlalchemy.org/docs/04/sqlalchemy_engine.html as an example, there are ways to improve this: thats not a good example to choose at all as the documentation has since been migrated to Sphinx, the templates have been rewritten, and completely new stylesheets developed which are generally the stock Sphinx sheets, with modifications to suit our slightly different navigation and color scheme. The current docs are at: http://www.sqlalchemy.org/docs/05/index.html the 0.4 series should be considered obsolete. if I were to change something with those docs, its that they'd be removed from the site entirely. otherwise if you have any advice on how to get 0.4/0.3 delisted from such a prominent place on Google, that would be appreciated. * Quasi syntax highlighting the function and it's arguments. Having def create(self, entity, **kwargs) all in bold is making it hard to browse through the functions by name as, at least, I often do. this is fixed in the current sphinx docs. I also takes some effort separating the arguments from each other. For instance, close_with_result=False is also all in bold. False should undoubtedly be of a different format than the argument name. AFAIK Sphinx and/or docutils doesn't support this (the markup generated is hardwired into docutils) - as an example you can see it on the Python site at http://docs.python.org/library/platform.html#module-platform . * Differentiate class documentation from function documentation. Today, the class header is just ~2px larger than the function header, i.e., not a big enough deviation. Using 30%+ larger header or wrapping it in a styled box should do it. we generally list out functions and classes in entirely different collections. docutils seems to generate different styles for classes and functions. It does put the word function or class and the Python docs don't seem to make any stylistic distinctions otherwise. * De-emphasizing back to section top. The link is almost the same size as the class ancestor (constructor argument), which requires effort to separate. that link does not exist in the Sphinx version of the documentation. * The darkcell div is indeed superfluous. One could create the same effect of division with white space and/or horizontal bordering. the gray background is only used for code examples and as a background for the function/class signature, and we no longer have large tracts of text written on a gray background.the latter is derived from what the Python documentation does for section headers. * Emphasizing class properties and module includes. The default indentation of definition data is not sufficient. * Generally using white space more efficiently. since these are somewhat vague comments I would ask that you consider the current Sphinx documentation for these 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Small note on reading SA docs
otherwise if you have any advice on how to get 0.4/0.3 delisted from such a prominent place on Google, that would be appreciated. The simplest thing to do is to append: Disallow: /docs/04/ Disallow: /docs/03/ to the file: http://www.sqlalchemy.org/robots.txt This tells google (and all well-behaved search engines) not to index those urls (and anything under them). The next time the googlebot comes through, it will see the new robots.txt and remove those pages from its index. This will take a couple weeks at most. You can learn more about robots.txt here: http://www.robotstxt.org/ The disadvantage to doing it that way is that you will lose the google juice (pagerank) for inbound links to the old documentation. An alternative approach that gets around this to use a link rel=canonical ... tag in the head of each page of the 04 and 03 documentation pointing to the corresponding page of 05 documentation as its canonical url. By doing this, you are claiming that the 04/ 03 documentation pages are duplicates of the corresponding 05 pages. Google juice from inbound links to an old documentation page will accrue to the appropriate 05 documentation page instead. However, strictly speaking, the different versions aren't quite duplicates, so you might be pushing the boundaries of what is allowed a bit by claiming they are. Here is more info on rel=canonical from google: http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html A similar approach would be to do a 301 redirect from each old documentation page to the corresponding 05 documentation page, but only if the visitor is the googlebot. This is straightforward to implement with mod_rewrite (the googlebot can be recognized by its user-agent string), but probably a bad idea since google usually considers it cloaking to serve different content to the googlebot than to regular visitors. You should also consider submitting an XML sitemap to google via the google webmaster tools. This allows you to completely spell out for them the structure of the site and what you want indexed. I also noticed that your current robots.txt file disallows indexing of anything under /trac/. It would nice to let google index bugs in trac so that someone who searches google for sqlalchemy help can come across an extant bug describing their problem. In addition, you have links on the front page (changelog and what's new) that go to urls under /trac/ , so google will not follow those links due to your robots.txt. --~--~-~--~~~---~--~~ 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: Small note on reading SA docs
Rereading what you posted, by such a prominent place on Google, did you mean specifically the .4 and .3 links that show up below sqlalchemy when www.sqlalchemy.org is returned in the search results? Those are what google calls sitelinks. You can tell them not to use certain pages as sitelinks via the google webmaster tools. They'll remove them, but they don't get replaced so you will have two fewer sitelinks then. On Thu, May 21, 2009 at 8:03 PM, Bobby Impollonia bob...@gmail.com wrote: otherwise if you have any advice on how to get 0.4/0.3 delisted from such a prominent place on Google, that would be appreciated. The simplest thing to do is to append: Disallow: /docs/04/ Disallow: /docs/03/ to the file: http://www.sqlalchemy.org/robots.txt This tells google (and all well-behaved search engines) not to index those urls (and anything under them). The next time the googlebot comes through, it will see the new robots.txt and remove those pages from its index. This will take a couple weeks at most. You can learn more about robots.txt here: http://www.robotstxt.org/ The disadvantage to doing it that way is that you will lose the google juice (pagerank) for inbound links to the old documentation. An alternative approach that gets around this to use a link rel=canonical ... tag in the head of each page of the 04 and 03 documentation pointing to the corresponding page of 05 documentation as its canonical url. By doing this, you are claiming that the 04/ 03 documentation pages are duplicates of the corresponding 05 pages. Google juice from inbound links to an old documentation page will accrue to the appropriate 05 documentation page instead. However, strictly speaking, the different versions aren't quite duplicates, so you might be pushing the boundaries of what is allowed a bit by claiming they are. Here is more info on rel=canonical from google: http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html A similar approach would be to do a 301 redirect from each old documentation page to the corresponding 05 documentation page, but only if the visitor is the googlebot. This is straightforward to implement with mod_rewrite (the googlebot can be recognized by its user-agent string), but probably a bad idea since google usually considers it cloaking to serve different content to the googlebot than to regular visitors. You should also consider submitting an XML sitemap to google via the google webmaster tools. This allows you to completely spell out for them the structure of the site and what you want indexed. I also noticed that your current robots.txt file disallows indexing of anything under /trac/. It would nice to let google index bugs in trac so that someone who searches google for sqlalchemy help can come across an extant bug describing their problem. In addition, you have links on the front page (changelog and what's new) that go to urls under /trac/ , so google will not follow those links due to your robots.txt. --~--~-~--~~~---~--~~ 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] Q: fetch value of autoincrement column
Hi, Is it possible to fetch the values of an autoincrement field without flushing the object to the DB? (In postgres, I obviously can manually fetch nextval of the automatically generated sequence, but I lose the portability that way ...) Why? Because I need the id to generate data that will be filled into some (non- null) columns of the table row. So I can't flush since I'll get an IntegrityError about non-null columns, and I can't fill those columns without knowing the id that's going to be assigned. (Yes, I can use dummy values, then flush(), and then update the row before committing. But that's not exactly elegant...) cheers -- vbi -- Fnord. signature.asc Description: This is a digitally signed message part.
