Michael Bayer wrote:

1. we dont really need two tables to test this, just any table with a column with a UNIQUE constraint, two objects mapped against that table with the same value for that column, delete one and save the other and there you go.

You're right, a single table would be adequate to demonstrate the problem. I 
included the relationship to give give you an idea of how the object was 
getting deleted (hence the comments on HistoryArraySet). I did that more 
because of what I was doing in my real application.


2. for a slight loss of efficiency, cant you put a "before_insert" mapper extension that essentially does this (substitute the appropriate SQL):

    def before_insert(self, mapper, instance, connection):
        alias = instance.alias
        random_string = alias + "_" + hex(random.randint(0, 65535))[2:]
        # update existing row to something else
connection.execute("update items set alias='%s' where alias='%s'" % (random_string, alias))

of course, if you *didnt* delete another record in that session, then youre just screwing with the table's data inappropriately. youd need some other way to give the mapper extension the "green light".

How would I get that "green light" signal? Is there some way I could check if 
an object with the alias-to-be-inserted is scheduled for deletion? The code you have 
prescribed totally circumvents the unique constraint. With that I'd probably never have a 
constraint violation, but I might end up with records with random aliases sticking 
around. I think I'll just remove the constraint altogether and build it into my 
application logic...ugh...


rewiring SA to do the delete before the insert....im skeptical of that since the order of operations is hugely sensitive to things being in the slightly incorrect order (Hibernate also does inserts first and deletes last....) . such as, inserts/deletes of items dependent on the Item rows occur after Item inserts and before Item deletes...if an Item is deleted up above the Item saves, now all the dependent object operations, for just that Item which is deleted, have to be shuffled around as well, screwing up their dependencies, etc...the current design of the dependency sorting is not too amenable to that kind of thing. (there is another idea i have to change the whole theory of the dependency sorting to something more table/row-oriented, but thats a long way off).


Hmm, that's sort of what I thought. I'll keep thinking about this one and let 
you know if I come up with anything better. Thanks for your insight.

~ Daniel


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users

Reply via email to