Eric Lemoine wrote: > On Sat, Apr 26, 2008 at 5:58 AM, Sean Gillies <[EMAIL PROTECTED]> wrote: >> Eric, >> >> Can you show me an traceback through SQLAlchemy where the geometry's >> equals predicate is used? > > Here it is: > > Module unhcr.controllers.refugees:80 in post >>> model.Session.commit() > Module sqlalchemy.orm.scoping:98 in do >>> return getattr(self.registry(), name)(*args, **kwargs) > Module sqlalchemy.orm.session:544 in commit >>> self.transaction.commit() > Module sqlalchemy.orm.session:250 in commit >>> self._prepare_impl() > Module sqlalchemy.orm.session:234 in _prepare_impl >>> self.session.flush() > Module sqlalchemy.orm.session:757 in flush >>> self.uow.flush(self, objects) > Module sqlalchemy.orm.unitofwork:233 in flush >>> flush_context.execute() > Module sqlalchemy.orm.unitofwork:445 in execute > UOWExecutor().execute(self, tasks) > Module sqlalchemy.orm.unitofwork:930 in execute > self.execute_save_steps(trans, task) > Module sqlalchemy.orm.unitofwork:945 in execute_save_steps >>> self.save_objects(trans, task) > Module sqlalchemy.orm.unitofwork:936 in save_objects >>> task.mapper._save_obj(task.polymorphic_tosave_objects, trans) > Module sqlalchemy.orm.mapper:1158 in _save_obj >>> mapper._postfetch(uowtransaction, connection, table, state, c, > c.last_inserted_params(), value_params) > Module sqlalchemy.orm.mapper:1198 in _postfetch >>> elif not c.primary_key and c.key in params and > self._get_state_attr_by_column(state, c) != params[c.key]: > Module shapely.geometry.base:255 in __ne__ >>> return not self.equals(other) > Module shapely.predicates:30 in __call__ >>> raise RuntimeError() # breakpoint FIXME > > > Also, I asked on the SQLAlchemy mailing list why there was a > comparison when creating a line in the database. Here's Michael > Bayer's response: > > ----- > "this (the comparison) occurs well after any attribute history > detection has happened > (which is where comparsions are supposed to happen, if needed). The > mapper has inserted the row, then it goes through the list of > parameters which were inserted into the row and compares them to what > is present on the object, so that it can detect Column-level defaults > and other "auto"-generated values which need to be placed on the > instance. This methodology is out of date since nowadays we have an > explicit listing of which columns were "auto" generated - so try out > the attached patch which refines the methodology in that section and > should solve the issue. The patch is also ticket #1015 which needs > test coverage before it can be committed (but is high priority for > 0.4.6)." > ---- > > His patch is attached (applies to SA trunk). I haven't tested it yet. > > Although, his patch may make my problem disappear, it doesn't solve > the actual bug, which I think lies either in Shapely or in GEOS. > AFAICT every geometry object created by Shapely is actually created by > GEOS, so GEOSEquals should never segfault when comparing geometry > objects. > > As a side note: I understood why in the debugger (in > BinaryPredicate.call) I always get different values for > self.context._geom and other._geom. It's because Shapely creates a new > GEOS object each time _geom is accessed (_geom is a @property). So > with the current Shapely code, it makes perfect sense that the two > _geom values given to GEOSEquals are different. What doesn't make > sense is that GEOSEquals segfault's, but you know that already :-) > > Thanks again, > > > -- > Eric
Eric, Let's take the discussion to http://trac.gispython.org/projects/PCL/ticket/163 I have a couple ideas for making things safer. Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
