OperationVetoedException - when updating an existing document
Paul Hinett
Hi,
Just upgraded to build 960 stable from 951, both client, server and bundles.
On a simple procedure of loading an existing document by id, updating 1 property (a DateTimeOffset property) I am getting an exception from the UniqueConstraint bundle.
I can’t seem to reproduce this locally on my dev machine but only on my production server.
var account = _documentSession.Load<Account>(command.AccountId);
account.LastNotificationReadDate = DateTimeOffset.Now;
Raven.Database.Exceptions.OperationVetoedException: PUT vetoed by Raven.Bundles.UniqueConstraints.UniqueConstraintsPutTrigger because: Ensure unique constraint violated for fields: ArtistName, EMail
Has anything changed that could cause this, it was working fine before the upgrade to latest stable.
Paul
Paul Hinett
I can reproduce this from the Silverlight management studio too, load up the document, modify and save it…get the same error.
I have downgraded the server to build 951 just to check if it fixes it, but it doesn’t which is strange.
I’m not 100% sure it was build 951 I was using previously to be quite honest, but it was around the 24th May i downloaded the latest build I was using.
This is affecting a large proportion of my site currently when saving any document related to a user account.
Paul
Oren Eini (Ayende Rahien)
Paul Hinett
I did this before, that is what caused the issue (I think).
I have updated to build 960 again and I’m running from the debug console, still getting the same problem.
Oren Eini (Ayende Rahien)
Paul Hinett
It’s not doing this locally on dev machine, only on production server with any save to an existing ‘Account’ document.
I would do a backup/restore to my local machine to test, but it takes over 24 hours.
Paul Hinett
This is only happening on old documents by the way, newly created documents seem to be working fine by the looks of it.
From: rav...@googlegroups.com [mailto:rav...@googlegroups.com] On Behalf Of Oren Eini (Ayende Rahien)
Sent: 09 June 2012 11:27
To: rav...@googlegroups.com
Paul Hinett
It seems to also only do this for specific documents, I’m not entirely sure which ones exactly or if there is any pattern to this, but some save ok, some don’t.
From: rav...@googlegroups.com [mailto:rav...@googlegroups.com] On Behalf Of Oren Eini (Ayende Rahien)
Sent: 09 June 2012 11:27
To: rav...@googlegroups.com
Oren Eini (Ayende Rahien)
Paul Hinett
I have noticed something weird.
In the actual unique constraint document of a working one, this is how it looks:
{
"RelatedId": "accounts-40132"
}
And a none working one:
{
"Id": "accounts-155"
}
Why is one using RelatedId, and the other Id?
Is this maybe the issue?
Paul
Oren Eini (Ayende Rahien)
Paul Hinett
Seems like an unnecessary breaking change?
Is there a list of breaking changes anywhere that I can check through when upgrading server builds?
What would be the recommended way to loop through all the invalid unique constraint documents and updating the Id field to RelatedId?