Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-18 Thread Ruben Di Battista
I confirm what I said. The run in multiprocessing was regenerating instances because after deserialization they were getting new IDs. I tried to implement a custom __hash__ but it seems that SQLAlchemy does not get it. What I did was disabling the backref cascade for `Satellite` and

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-17 Thread Ruben Di Battista
I was not able to find anything generating new instances. In facts the culprit was that with the `prop.schedule()` method I'm using multiprocessing. So the instances of the `Passage` objects that are in different processes, gain a different `id` (and moreover they're referenced instances of

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-15 Thread Simon King
Yes, if you can't find where you are creating new Satellite instances, I'd probably stick an assert statement in Satellite.__init__ and see where it gets triggered. Simon On Mon, Jan 15, 2018 at 10:34 AM, Ruben Di Battista wrote: > Dear Simon, > > thanks again for

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-15 Thread Ruben Di Battista
Dear Simon, thanks again for your kind help. Actually the creation of new instances is not intended. But I'm not getting where they are created... I give you more insight: This is the scheduler object with the associated propagate() method class Scheduler(six.with_metaclass(abc.ABCMeta)):

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-15 Thread Simon King
On Sat, Jan 13, 2018 at 3:31 PM, Ruben Di Battista wrote: > > > On Friday, January 12, 2018 at 10:54:49 AM UTC+1, Simon King wrote: >> >> If I understand your code correctly, scheduler.propagate() creates a >> large number of Passage instances, and you only want a small

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-13 Thread Ruben Di Battista
On Friday, January 12, 2018 at 10:54:49 AM UTC+1, Simon King wrote: > > If I understand your code correctly, scheduler.propagate() creates a > large number of Passage instances, and you only want a small subset of > them to be added to the database. Is that correct? > Correct! > I would

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-12 Thread Simon King
If I understand your code correctly, scheduler.propagate() creates a large number of Passage instances, and you only want a small subset of them to be added to the database. Is that correct? I would guess that the passages are getting added to the session because you are setting their 'satellite'

Re: [sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-11 Thread Mike Bayer
I can't give you much detail except to say the unique object recipe is doing an .add() when it finds an identity that isn't taken, if you don't want those persisted then take out the part of the recipe doing add(). However, you'd need to alter the recipe further such that if the program asks for

[sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-11 Thread Ruben Di Battista
Last copy paste went wrong. The uniqueness is ensured by: @event.listens_for(orm.session.Session, "after_attach") def after_attach(session, instance): # when ConstrainedSatellite objects are attached to a Session, # figure out if in the database there's already the Constraint, #

[sqlalchemy] Re: Temporarily disable DB persistence for optimization routine

2018-01-11 Thread Ruben Di Battista
Dear Mike, thank you for the fast response as usual. Your comment made me think. Actually I was not adding things in the session directly. I revised my code and I believe the behaviour I'm describing is related to the application of the UniqueObject patter described in the documentation.