So based on your input (thank you!), would this be satisfactory?
{{{
def do_db_upgrade(self):
upgradeprogress = 0
with self.env.db_transaction as db:
try:
cursor = db.cursor()
if self.db_installed_version < 1:
contacts_table = Table('contact', key=('id',))[
Column('id', type='int', auto_increment=True),
Column('first'),
Column('last'),
Column('position'),
Column('email'),
Column('phone'),
Index(['id'],unique=True)
]
print 'Adding Contacts Table'
for stmt in to_sql(self.env, contacts_table):
print "Executing %s" % stmt
cursor.execute(stmt)
upgradeprogress = 1
print "Updating System Table"
print "Executing INSERT into system values
('contacts_version', %s)"%(str(self.db_version),)
cursor.execute("INSERT into system values
('contacts_version', %s)",str(self.db_version))
raise Exception("Intentional Exception")
except Exception as e:
print "Exception while performing contacts upgrade occured:
%s" % e
self.log.error("Exception while performing contacts upgrade
occured: %s" % e)
db.rollback()
if upgradeprogress > 0:
try:
with self.env.db_transaction as db:
cursor = db.cursor()
cursor.execute("drop table if exists contact")
except Exception as e:
print "Could not roll back contact table creation:
%s" % e
self.log.error("Could not roll back contact table
creation: %s" % e)
}}}
This results in a repeatable error output with each execution:
{{{
No installed contacts table.
Contacts needs an upgrade
* Upgrading db
Adding Contacts Table
Executing CREATE TABLE contact (
id integer PRIMARY KEY,
first text,
last text,
position text,
email text,
phone text
);
Executing CREATE UNIQUE INDEX contact_id_idx ON contact (id);
Updating System Table
Executing INSERT into system values ('contacts_version', 1)
Exception while performing contacts upgrade occured: Intentional Exception
Done Upgrading
Upgrade done.
}}}
Does dropping the table remove the index? It looked like it did. I
hesitate to use "drop index if exists contact_id_idx" because I don't know
if the index is named in similar fashion across other db backends by the
to_sql statement?
Removing the intentional exception upgrades the db successfully. I have
to try this with MySQL, but on a first glance does it look like it will be
portable? Thank you very much!
Steffen, thank you for your efforts as well. I am part of a very
small (relative to the agency) team within the FAA doing test and
evaluation on systems provided through contract vehicles. Our team had a
chance to go with a much more expensive solution for tracking tickets, but
hopefully I can get Trac to meet or exceed our needs and save taxpayers a
little money.
-Nelson
On Sat, Nov 19, 2011 at 7:31 AM, Christian Boos <[email protected]>wrote:
> Hello,
>
> On 11/18/2011 11:37 PM, Nelson Brown wrote:
>
>> ...
>>
>> * Upgrading db
>> Adding Contacts Table
>> Executing CREATE TABLE contact (
>> id integer PRIMARY KEY,
>> first text,
>> last text,
>> position text,
>> email text,
>> phone text
>> );
>> Executing CREATE UNIQUE INDEX contact_id_idx ON contact (id);
>> Updating System Table
>> Executing INSERT into system values ('contacts_version', 1)
>> Exception: Intentional Exception
>>
>> And when I run trac-admin upgrade directly subsequent on the same
>> environment.
>>
>> No installed contacts table.
>> Contacts needs an upgrade
>> * Upgrading db
>> Adding Contacts Table
>> Executing CREATE TABLE contact (
>> id integer PRIMARY KEY,
>> first text,
>> last text,
>> position text,
>> email text,
>> phone text
>> );
>> OperationalError: table contact already exists
>>
>>
>> So the system table was the only execute statement to be rolled back in
>> the with block. Otherwise, we wouldn't be in this method. So is that
>> intentional?
>>
>
> It's rather that you can't really avoid it, as some backends (like SQLite)
> can't rollback changes to the data model (the DDL statements like CREATE
> TABLE, ALTER TABLE, etc.). One workaround would be to record what you
> created and at the end, if you detect that a rollback happened, drop the
> tables and indexes which have been created so far.
>
> -- Christian
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to trac-dev+unsubscribe@**
> googlegroups.com <trac-dev%[email protected]>.
> For more options, visit this group at http://groups.google.com/**
> group/trac-dev?hl=en <http://groups.google.com/group/trac-dev?hl=en>.
>
>
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
