AcidState feature request

[Maxim Savchenko]

Hello again!

Can we please have MonadError instance for Query and Update? Right now layering ErrorT over them results in unusable makeAcidic TH macro and manual rollback on exceptions. As far as I see, this feature can be added without breaking compatibility - with String as default error type and monadic fail as default catchError behavior for update and request. 

[David Himmelstrup]

Exception handling is a tricky subject and I do not believe adding a MonadError instance is the right way to go. Keep in mind that you can always define your own monads instead of using Query and Update.

-- 

David Himmelstrup

On Monday, April 1, 2013 at 5:42 PM, Maxim Savchenko wrote:

Hello again!

Can we please have MonadError instance for Query and Update? Right now layering ErrorT over them results in unusable makeAcidic TH macro and manual rollback on exceptions. As far as I see, this feature can be added without breaking compatibility - with String as default error type and monadic fail as default catchError behavior for update and request. 

--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to happs+un...@googlegroups.com.
To post to this group, send email to ha...@googlegroups.com.
Visit this group at http://groups.google.com/group/happs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Petter Bergman]

You can have any monad transformer stack you want to run your transactions in, but you need to run the transformer stack so you end up with either a Query or Update.

2013/4/1 Maxim Savchenko <pdu...@gmail.com>

Hello again!

Can we please have MonadError instance for Query and Update? Right now layering ErrorT over them results in unusable makeAcidic TH macro and manual rollback on exceptions. As far as I see, this feature can be added without breaking compatibility - with String as default error type and monadic fail as default catchError behavior for update and request. 

--

[Maxim Savchenko]

Hm... I'm not very experienced haskell developer and thought that MonadError is sort of standart way of dealing with exceptions in pure code. I'm not insisting on this particular class - just asking of _some_ exception handling to appear. Need to throw an error while rolling back changes is pretty common in any ACID-using application larger then hello world. Of course, stacking monad transformers solves this, but in price of small annoyances, like loosing ease of makeAcidic - and this makes me sad.

понедельник, 1 апреля 2013 г., 19:53:26 UTC+4 пользователь Lemmih написал:

[David Himmelstrup]

You should still be able to use 'makeAcidic' even if you use your own transformer stack. Just make sure you always end up with either a Query or Update.

-- 

David Himmelstrup

[dag.od...@gmail.com]

Do you mean runErrorT in every event function?

[David Himmelstrup]

Yes.

[Petter Bergman]

Depending on the OP's needs, it might be OK to just use "error".

2013/4/1 David Himmelstrup <lem...@gmail.com>

[Maxim Savchenko]

Hm... I'm currently catching some of exceptions inside Update monad before falling out to the IO and this is quite handy. But if Control.Exception is recommended way for acid-state, I do not mind rewriting this. I suppose, I do have guaranty that all state changes made before throw or error call are reverted? (btw, now I'm getting why ST-mutable data can't be stored - stupid me)

понедельник, 1 апреля 2013 г., 22:02:32 UTC+4 пользователь Petter написал:

[David Himmelstrup]

Yes, if you throw an exception then all state changes will be discarded.

But be watchful for deeply nested exceptions. For example, returning '[1,2,3,error "urk"]' will not cause AcidState to revert the transaction since the exception hasn't been thrown yet.

-- 

David Himmelstrup

[Maxim Savchenko]

Auch. Almost forgot why I'm afraid of Control.Exception in pure context - perfect way of shooting yourself in the foot! I'll better be writing runErrorT here and there...

понедельник, 1 апреля 2013 г., 23:18:13 UTC+4 пользователь Lemmih написал:

[Petter Bergman]

Here's what I did:

I wrote all my transactions using my own monad transformer stack (I had State, Reader and Error), I put them in their own module, Raw.

In another module Transactions, I import the Raw module qualified. And put a bunch of lines like

myUpdate param1 param2 = runMyMonadStackAsUpdate $ Raw.myUpdate param1 param2

and then you call makeAcidic on all the transactions in this module.

runMyMonadStackAsUpdate should return an Update YourDbType (Either YourErrorType a), if the action throws an error it should also discard the update.

Then I wrote my own versions of update and query that handles the Either returned from the transactions. In my case I throw an exception in the Snap monad (yes, I use snap, but it would be more or less the same with happstack) in case the result is a Left.

In this application I had quite "Heavy" transactions, with a lot of work being done inside the transactions. For my next project I will try to have more lightweight transactions, and see if I can do without all these transformer stacks.

/PB

2013/4/1 Maxim Savchenko <pdu...@gmail.com>