Ayende @ Rahien

Daniel Lang commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Tue, 05 Jun 2012 21:36:05 GMT

Thanks for sharing this useful series. It was really interesting to see how such decisions are made up.

Alex Beynenson commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Mon, 04 Jun 2012 15:30:56 GMT

I like the option that the exception is thrown. To me that's way more elegant than a custom error handling delegate. If you squint just right, it pretty much looks like a try/catch block anyway.

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Sat, 02 Jun 2012 10:57:10 GMT

Andreas, Note that you are free to implement local solutions, and you _can_ do that, quite easily. You can give specific error messages, you can change behavior based on the current context, etc.

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Sat, 02 Jun 2012 10:56:13 GMT

Lucas, Then an exception is thrown.

Lucas Ontivero commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Sat, 02 Jun 2012 01:19:24 GMT

Question: what if the developer doesn´t provide an error handler? Will he gets an exception?

Paulo Köch commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 16:12:50 GMT

Very elegant. My hat is off to you. Again. :P

Jason Pettys commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 16:04:54 GMT

Beautiful solution.

Paul Stovell commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 15:16:43 GMT

+1 to Omer's suggestion of using an enum. True/false is ambiguous here.

Daniel commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 11:24:02 GMT

I'm curious. Why returning true/false instead of having an IgnoreError property on one of the parameters?

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 11:11:01 GMT

Knagis, You are welcome to handle this in any way you see fit. You can introduce your own logic, build your own decisions, etc. And we only need a single event handler that returns true.

Omer Mor commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 11:09:34 GMT

Oren, I suggest you change the signature of the OnError event to return an enum instead of a bool. This would be more self-documenting. That way you'll return something like ErrorHandling.Handled or ErrorHandling.RethrowException. What do you think?

Damien commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 10:24:38 GMT

Knaģis - I think you may have answered the first part of your question with the second. I presume the return value is meant to represent "handled". If there's one style of query that needs special handling, register it as an earlier event handler, and leave the "generic" handler as the last one subscribed. So "the" event handler doesn't grow uncontrollably, because you register multiple ones. Of course, I might be completely misreading the intent of this design.

Knaģis commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Fri, 01 Jun 2012 10:19:42 GMT

Won't this result in the OnError handler growing out of proportion since in more complex usage scenarios it will have to be extended to analyse each different query to determine if it is allowed to continue? What about a scenario where the same query can be partial (for example, displaying posts to the user in a webpage) and cannot be partial (for example, the same posts but now for some sort of persistant media)? I'm all for global solutions but I always try to use that for defaults but allow the dev to override it where needed. Also why do you designed the OnError with a return value instead of using EventArgs? What happens if two handlers return True and one - False?

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Mon, 09 Apr 2012 18:20:59 GMT

Vlad, I don't see a reason to try to have different behaviors for different sessions, in most cases, you simply won't have any need for that, and when you do, you can handle that yourself.

Vlad commented on API Design: Sharding Status for failure scenarios–Solving at the right granularity

Mon, 09 Apr 2012 16:15:26 GMT

Oren, I agree that additional parameters for data retrieving methods like Load<> is bad way because pure abstraction of repository will be broken. At this stage user should not have possibility to manage/audit low-level logic. And solution described in this post possibly is better because ShardAccessStrategy is responsible point for sharding behavior definition. But ShardAccessStrategy belongs to ShardedDocumentStore which is not user action- (request-) specific as IDocumentSession. If we have a system using principle request/response we need to use some state related to DocumentStore that's no good. I suggest to make this session-related. 1. IDocumentStore.OpenSession(). Usual session fabric method. 2. IDocumentStore.OpenSession(ISessionErrorHandler). Additional fabric method. 3. ShardedDocumentStore{//try-catch on ShardAccessStrategy.Apply(commands) and if ISessionErrorHandler == null then throw;} I'm not sure that is the best solution.