Thanks Oren - scared to enable that on the live server though which is the only place that is getting these.
BUT: if you say it's expected and we catch it and deal with it then I guess it's not doing to do any harm (except the last user won't get their write - which actually doesn't matter for this app)
It's up to you to decide what a concurrency exception means. You can either reject the write (easiest), or you can attempt to merge the changes into the newest document (not exceedingly hard, but can lead to unintended consequences), dump the documents into a conflict resolution queue that a human will then parse the correct state of the object (hardest/most work)
On Thursday, May 24, 2012 4:21:39 PM UTC-4, lunarjetset wrote:
> Thanks Oren - scared to enable that on the live server though which is > the only place that is getting these.
> BUT: if you say it's expected and we catch it and deal with it then I > guess it's not doing to do any harm (except the last user won't get > their write - which actually doesn't matter for this app)
Yeah, if you just catch the exception and move on, that means you are rejecting that particular write. That's the easiest way of handling issues with concurrent writes because the RavenDB api does most of the work for you, you just have to catch the exception.
Generally if you're going to go with rejecting the write, you want to inform the user that submitted that as best as possible.
On a more global level, my goals with usage of RavenDB is to hook in SignalR between the html client & MVC3 server such that if anyone modifies documents that other users have open in their browsers that they'll either get full change information immediately, or at the very least be informed preemptively that the document has changed and it needs to be reloaded before editing can continue. As opposed for them to do their work completely, THEN find out it's rejected.
> Generally if you're going to go with rejecting the write, you want to > inform the user that submitted that as best as possible.
> On a more global level, my goals with usage of RavenDB is to hook in > SignalR between the html client & MVC3 server such that if anyone > modifies documents that other users have open in their browsers that > they'll either get full change information immediately, or at the very > least be informed preemptively that the document has changed and it > needs to be reloaded before editing can continue. As opposed for them > to do their work completely, THEN find out it's rejected.
> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
> thanks Chris - good advice. When you say reject the write - do
> you mean just catch the exception and move on? Or is there a
> better way?
On Friday, 25 May 2012 13:28:53 UTC+1, Chris Marisic wrote:
> Generally if you're going to go with rejecting the write, you want to > inform the user that submitted that as best as possible.
> On a more global level, my goals with usage of RavenDB is to hook in > SignalR between the html client & MVC3 server such that if anyone modifies > documents that other users have open in their browsers that they'll either > get full change information immediately, or at the very least be informed > preemptively that the document has changed and it needs to be reloaded > before editing can continue. As opposed for them to do their work > completely, THEN find out it's rejected.
> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>> thanks Chris - good advice. When you say reject the write - do you mean >> just catch the exception and move on? Or is there a better way?
Your problem domain must be incredibly collaborative to demand the
complexity of the kind of solution you're suggesting. Is it really common
for two users to be changing the same data element at roughly the same time
in your domain?
On Fri, May 25, 2012 at 11:46 AM, jamesfarrer <james.far...@gmail.com>wrote:
> This sounds a really interesting approach. If you fancy writing a blog
> post on what you're doing then that would be wonderful!
> James
> On Friday, 25 May 2012 13:28:53 UTC+1, Chris Marisic wrote:
>> Generally if you're going to go with rejecting the write, you want to
>> inform the user that submitted that as best as possible.
>> On a more global level, my goals with usage of RavenDB is to hook in
>> SignalR between the html client & MVC3 server such that if anyone modifies
>> documents that other users have open in their browsers that they'll either
>> get full change information immediately, or at the very least be informed
>> preemptively that the document has changed and it needs to be reloaded
>> before editing can continue. As opposed for them to do their work
>> completely, THEN find out it's rejected.
>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>> thanks Chris - good advice. When you say reject the write - do you mean
>>> just catch the exception and move on? Or is there a better way?
On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com> wrote:
> Generally if you're going to go with rejecting the write, you want to
> inform the user that submitted that as best as possible.
> On a more global level, my goals with usage of RavenDB is to hook in
> SignalR between the html client & MVC3 server such that if anyone modifies
> documents that other users have open in their browsers that they'll either
> get full change information immediately, or at the very least be informed
> preemptively that the document has changed and it needs to be reloaded
> before editing can continue. As opposed for them to do their work
> completely, THEN find out it's rejected.
> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>> thanks Chris - good advice. When you say reject the write - do you mean
>> just catch the exception and move on? Or is there a better way?
On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
> Chris, > Note that this is a planned 1.2 feature.
> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com> wrote:
>> Generally if you're going to go with rejecting the write, you want to >> inform the user that submitted that as best as possible.
>> On a more global level, my goals with usage of RavenDB is to hook in >> SignalR between the html client & MVC3 server such that if anyone modifies >> documents that other users have open in their browsers that they'll either >> get full change information immediately, or at the very least be informed >> preemptively that the document has changed and it needs to be reloaded >> before editing can continue. As opposed for them to do their work >> completely, THEN find out it's rejected.
>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>> thanks Chris - good advice. When you say reject the write - do you mean >>> just catch the exception and move on? Or is there a better way?
On Tue, May 29, 2012 at 3:23 PM, Chris Marisic <ch...@marisic.com> wrote:
> What exactly is a 1.2 feature?
> On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
>> Chris,
>> Note that this is a planned 1.2 feature.
>> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> Generally if you're going to go with rejecting the write, you want to
>>> inform the user that submitted that as best as possible.
>>> On a more global level, my goals with usage of RavenDB is to hook in
>>> SignalR between the html client & MVC3 server such that if anyone modifies
>>> documents that other users have open in their browsers that they'll either
>>> get full change information immediately, or at the very least be informed
>>> preemptively that the document has changed and it needs to be reloaded
>>> before editing can continue. As opposed for them to do their work
>>> completely, THEN find out it's rejected.
>>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>>> thanks Chris - good advice. When you say reject the write - do you
>>>> mean just catch the exception and move on? Or is there a better way?
On Tuesday, May 29, 2012 8:33:36 AM UTC-4, Oren Eini wrote:
> A feature that is planned for 1.2 release
> On Tue, May 29, 2012 at 3:23 PM, Chris Marisic <ch...@marisic.com> wrote:
>> What exactly is a 1.2 feature?
>> On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
>>> Chris, >>> Note that this is a planned 1.2 feature.
>>> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>> Generally if you're going to go with rejecting the write, you want to >>>> inform the user that submitted that as best as possible.
>>>> On a more global level, my goals with usage of RavenDB is to hook in >>>> SignalR between the html client & MVC3 server such that if anyone modifies >>>> documents that other users have open in their browsers that they'll either >>>> get full change information immediately, or at the very least be informed >>>> preemptively that the document has changed and it needs to be reloaded >>>> before editing can continue. As opposed for them to do their work >>>> completely, THEN find out it's rejected.
>>>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>>>> thanks Chris - good advice. When you say reject the write - do you >>>>> mean just catch the exception and move on? Or is there a better way?
On Tue, May 29, 2012 at 3:38 PM, Chris Marisic <ch...@marisic.com> wrote:
> What exactly is the feature you're saying is in 1.2
> On Tuesday, May 29, 2012 8:33:36 AM UTC-4, Oren Eini wrote:
>> A feature that is planned for 1.2 release
>> On Tue, May 29, 2012 at 3:23 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> What exactly is a 1.2 feature?
>>> On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
>>>> Chris,
>>>> Note that this is a planned 1.2 feature.
>>>> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>> Generally if you're going to go with rejecting the write, you want to
>>>>> inform the user that submitted that as best as possible.
>>>>> On a more global level, my goals with usage of RavenDB is to hook in
>>>>> SignalR between the html client & MVC3 server such that if anyone modifies
>>>>> documents that other users have open in their browsers that they'll either
>>>>> get full change information immediately, or at the very least be informed
>>>>> preemptively that the document has changed and it needs to be reloaded
>>>>> before editing can continue. As opposed for them to do their work
>>>>> completely, THEN find out it's rejected.
>>>>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>>>>> thanks Chris - good advice. When you say reject the write - do you
>>>>>> mean just catch the exception and move on? Or is there a better way?
Not that I'm diminishing the importance of those notifications as there are many scenarios that they will matter for, however for the described scenario:
user1 on abc user2 on abc
user2 modifies abc
tell user1 abc has been modified
The change notification from the database doesn't go far for telling user1. This would still likely involve SignalR (not saying this is Raven's responsibility just stating this) so that I could inform the client for user1. Now this theoretically could be VERY easy with signalR + raven change notifications because I store my documents using IDs that are the actual true URL slugs to access the resource through REST so it could potentially be very easy to find all clients that are connected to "mydoc/abc"
This seems like a very logical seperation of concerns for Raven to not take a full on dependency to signalR but provide the tools (change notifications) to make working with SignalR very straightforward. Instead of the current scenario where you'd need to hold some kind of dictionary for every user of what documents they have open, and then when any document changes trying to walk all users dictionaries to find if any contain that, then obviously keeping the dictionaries up to date etc.
On Tuesday, May 29, 2012 8:42:05 AM UTC-4, Oren Eini wrote:
> Notifications for changes in the db.
> On Tue, May 29, 2012 at 3:38 PM, Chris Marisic <ch...@marisic.com> wrote:
>> What exactly is the feature you're saying is in 1.2
>> On Tuesday, May 29, 2012 8:33:36 AM UTC-4, Oren Eini wrote:
>>> A feature that is planned for 1.2 release
>>> On Tue, May 29, 2012 at 3:23 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>> What exactly is a 1.2 feature?
>>>> On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
>>>>> Chris, >>>>> Note that this is a planned 1.2 feature.
>>>>> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>> Generally if you're going to go with rejecting the write, you want to >>>>>> inform the user that submitted that as best as possible.
>>>>>> On a more global level, my goals with usage of RavenDB is to hook in >>>>>> SignalR between the html client & MVC3 server such that if anyone modifies >>>>>> documents that other users have open in their browsers that they'll either >>>>>> get full change information immediately, or at the very least be informed >>>>>> preemptively that the document has changed and it needs to be reloaded >>>>>> before editing can continue. As opposed for them to do their work >>>>>> completely, THEN find out it's rejected.
>>>>>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>>>>>> thanks Chris - good advice. When you say reject the write - do you >>>>>>> mean just catch the exception and move on? Or is there a better way?
On Tue, May 29, 2012 at 4:46 PM, Chris Marisic <ch...@marisic.com> wrote:
> Not that I'm diminishing the importance of those notifications as there
> are many scenarios that they will matter for, however for the described
> scenario:
> user1 on abc
> user2 on abc
> user2 modifies abc
> tell user1 abc has been modified
> The change notification from the database doesn't go far for telling
> user1. This would still likely involve SignalR (not saying this is Raven's
> responsibility just stating this) so that I could inform the client for
> user1. Now this theoretically could be VERY easy with signalR + raven
> change notifications because I store my documents using IDs that are the
> actual true URL slugs to access the resource through REST so it could
> potentially be very easy to find all clients that are connected to
> "mydoc/abc"
> This seems like a very logical seperation of concerns for Raven to not
> take a full on dependency to signalR but provide the tools (change
> notifications) to make working with SignalR very straightforward. Instead
> of the current scenario where you'd need to hold some kind of dictionary
> for every user of what documents they have open, and then when any document
> changes trying to walk all users dictionaries to find if any contain that,
> then obviously keeping the dictionaries up to date etc.
> On Tuesday, May 29, 2012 8:42:05 AM UTC-4, Oren Eini wrote:
>> Notifications for changes in the db.
>> On Tue, May 29, 2012 at 3:38 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> What exactly is the feature you're saying is in 1.2
>>> On Tuesday, May 29, 2012 8:33:36 AM UTC-4, Oren Eini wrote:
>>>> A feature that is planned for 1.2 release
>>>> On Tue, May 29, 2012 at 3:23 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>> What exactly is a 1.2 feature?
>>>>> On Saturday, May 26, 2012 3:24:08 AM UTC-4, Oren Eini wrote:
>>>>>> Chris,
>>>>>> Note that this is a planned 1.2 feature.
>>>>>> On Fri, May 25, 2012 at 3:28 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>> Generally if you're going to go with rejecting the write, you want
>>>>>>> to inform the user that submitted that as best as possible.
>>>>>>> On a more global level, my goals with usage of RavenDB is to hook in
>>>>>>> SignalR between the html client & MVC3 server such that if anyone modifies
>>>>>>> documents that other users have open in their browsers that they'll either
>>>>>>> get full change information immediately, or at the very least be informed
>>>>>>> preemptively that the document has changed and it needs to be reloaded
>>>>>>> before editing can continue. As opposed for them to do their work
>>>>>>> completely, THEN find out it's rejected.
>>>>>>> On Friday, May 25, 2012 5:31:35 AM UTC-4, lunarjetset wrote:
>>>>>>>> thanks Chris - good advice. When you say reject the write - do you
>>>>>>>> mean just catch the exception and move on? Or is there a better way?
