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
