new TransactionFieldsNotChanged error

[Matthew Scott]

Pat,

Thanks again for your help getting the nongtk-41 branch going yesterday.

Here is the offending transaction that is causing the
TransactionFieldsNotChanged error:

class _Reorder(T.Transaction):

route = f.entity('Route')

def _execute(self, db):
def key(route_stop):
return route_stop.order
stops = sorted(
self.route.sys.links('RouteStop', 'route'), key=key)
db.RouteStop.relax_index('route', 'order')
order = 0
for stop in stops:
order += 1
db.execute(stop.t.update(order=order))
db.RouteStop.enforce_index('route', 'order')

I could change the logic to this instead:

if stop.order != order:
db.execute(stop.t.update(order=order))

Because of the algorithm, and the fact that I'm relaxing then enforcing
an index, to me it's a little clearer if the update would just succeed
even if nothing changes.

The algorithm doesn't really care what the old order was in the loop --
all it cares about is setting a new order, regardless of what the old
one is. Having the extra 'if' statement, IMHO, detracts from that, not
to mention adding a line of code that wasn't necessary before.

Thus begins the brainstorming of how to provide a "switch" between the
old behavior and the new, and what the default behavior should be :)

The rationale behind the exception you gave, IIRC, is that it is to
prevent side-effects from a custom Update transaction when no fields
have changed.

That would seem like behavior that is very specific though. When I
think about databases in general, I don't think I've run into a case
where an update operation where no fields have changed and where there
are no additional side-effects defined does anything exceptional.

Because this behavior is specific to schevo.transaction.Update, perhaps
a class-level attr, "_require_changes", defaulting to False, would
determine whether or not its _execute method raised an exception if no
changes had been made, or if it happily increments its entity's revision
number and performs any additional side-effects that may be defined.

This would allow non-customized updates to occur as they had prior to
this change, would allow custom updates to easily enforce a requirement
to have at least one field changed, and would also allow custom updates
to not require field changes but still perform additional side-effects,
if that is something a user desires.

I've implemented this behavior in r2358 of the nongtk-41 branch. If
this will work for your needs, I'll call this branch good and merge it
into trunk so we can get a Schevo release out on Tuesday or so.