Done, pushed.
On Thu, Mar 10, 2011 at 11:13:30AM -0800, Ethan Jackson wrote: > Oh of course please run make check before merging. > > Ethan > > On Thu, Mar 10, 2011 at 11:11 AM, Ethan Jackson <[email protected]> wrote: > > Thanks for writing these up. Both incrementals look good. Two very > > minor aesthetic comments. Go ahead and push. > > > > + If "isRoot" is omitted or specified as false, then any given row > > + in the table may exist only when it there is at least one > > "only when there is" > > > > - def to_json(self): > > + def to_json(self, default_is_root=False): > > + """Returns this table schema serialized into JSON. > > + > > + The "isRoot" member is included in the JSON only if its value would > > Trailing whitespace here. > > > > Ethan > > > > On Wed, Mar 9, 2011 at 3:56 PM, Ben Pfaff <[email protected]> wrote: > >> Here's an additional incremental that should be applied on top. I > >> haven't tested it yet. > >> > >> diff --git a/debian/openvswitch-switch.init > >> b/debian/openvswitch-switch.init > >> index 92ab775..8ea5866 100755 > >> --- a/debian/openvswitch-switch.init > >> +++ b/debian/openvswitch-switch.init > >> @@ -232,6 +232,18 @@ case "$1" in > >> cksum=`ovsdb-tool db-cksum "$conf_file" | awk '{print $1}'` > >> cp "$conf_file" "$conf_file.backup$version-$cksum" > >> > >> + # Compact database. This is important if the old schema did > >> not > >> + # enable garbage collection (i.e. if it did not have any > >> tables > >> + # with "isRoot": true) but the new schema does. In that > >> situation > >> + # the old database may contain a transaction that creates a > >> record > >> + # followed by a transaction that creates the first use of the > >> + # record. Replaying that series of transactions against the > >> new > >> + # database schema (as "convert" does) would cause the record > >> to be > >> + # dropped by the first transaction, then the second > >> transaction > >> + # would cause a referential integrity failure (for a strong > >> + # reference). > >> + ovsdb-tool -vANY:console:emer compact $conf_file > >> + > >> # Upgrade or downgrade schema and compact database. > >> ovsdb-tool -vANY:console:emer convert $conf_file $schema_file > >> fi > >> diff --git a/xenserver/etc_init.d_openvswitch > >> b/xenserver/etc_init.d_openvswitch > >> index 13b9d40..7300981 100755 > >> --- a/xenserver/etc_init.d_openvswitch > >> +++ b/xenserver/etc_init.d_openvswitch > >> @@ -341,7 +341,18 @@ function start { > >> cksum=`$ovsdb_tool db-cksum "$OVSDB_SERVER_DB" | awk '{print $1}'` > >> cp "$OVSDB_SERVER_DB" "$OVSDB_SERVER_DB.backup$version-$cksum" > >> > >> - # Upgrade or downgrade schema and compact database. > >> + # Compact database. This is important if the old schema did not > >> enable > >> + # garbage collection (i.e. if it did not have any tables with > >> "isRoot": > >> + # true) but the new schema does. In that situation the old > >> database > >> + # may contain a transaction that creates a record followed by a > >> + # transaction that creates the first use of the record. > >> Replaying that > >> + # series of transactions against the new database schema (as > >> "convert" > >> + # does) would cause the record to be dropped by the first > >> transaction, > >> + # then the second transaction would cause a referential integrity > >> + # failure (for a strong reference). > >> + $ovsdb_tool -vANY:console:emer compact "$OVSDB_SERVER_DB" > >> + > >> + # Upgrade or downgrade schema. > >> $ovsdb_tool -vANY:console:emer convert "$OVSDB_SERVER_DB" > >> "$VSWITCHD_OVSDB_SCHEMA" > >> fi > >> > >> > >> _______________________________________________ > >> dev mailing list > >> [email protected] > >> http://openvswitch.org/mailman/listinfo/dev > >> > > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
