Should .save() be transactional by default? Bring back the DAO?

[basejump (Josh)]

1. Should calling save on a a domain be transactional by default?
- if not, then what is the general perspective on failed saves when cascades are in effect on associations?
- it seems dangerous not to have the scaffolding abide by an obvious transactional pattern by default
2. Should a "DAO" pattern or "resolver" pattern be more integral to Grails.
- it fairly hard to setup a standard transactional way of overriding persistence for a domain.
- sure there are event, but those are not transactional and they complicate the domain.
- once you get beyond what validation can do for you then it can become a non standard mish mash of sorts with a transactional service
3. Has anyone done any kind of work on a resolver pattern for Domains? or anything to bring back the dao?

I am trying to bring some standardization across our apps and plugins. Dejavu started to kick in. Could be habit in my design but I keep seeing the same stuff over and over.





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[drosowsk]

Hi Josh,

Post by basejump (Josh)
I am trying to bring some standardization across our apps and plugins.
Dejavu started to kick in. Could be habit in my design but I keep seeing
the same stuff over and over.

Same here especially since we're using hibernate envers on some domain
classes which requires transactions to populate its _aud tables.

Wouldn't it be a good idea to make transactions configurable, i.e. in
Config.groovy?

Cheers,
Daniel


-----
Agrenon GmbH
www.agrenon.com
--
View this message in context: http://grails.1312388.n4.nabble.com/Should-save-be-transactional-by-default-Bring-back-the-DAO-tp3559922p3560175.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[basejump (Josh)]

you have another great example with envers.

the example I ran into is a simple cascade save of an association where we were saving a Parent with new Child. The casacded kicked in and new Child saved and blew up saving Parent.
In other cases we are fine and have a bunch of services that are basically the dao pattern. I'd like them to be called dao as thats closer to what they are.

I am seeing a lot of repetition in our design and the default Controller scaffolding is more or less a non-transactional Dao service pattern
I am refactoring out the boiler plate code and putting together a Dao plugin. Should be done with it today.

What I have so far is here
https://github.com/basejump/grails-dao

Let me know your thoughts

Post by drosowsk
Hi Josh,

Post by basejump (Josh)
I am trying to bring some standardization across our apps and plugins.
Dejavu started to kick in. Could be habit in my design but I keep seeing
the same stuff over and over.

Same here especially since we're using hibernate envers on some domain
classes which requires transactions to populate its _aud tables.
Wouldn't it be a good idea to make transactions configurable, i.e. in
Config.groovy?
Cheers,
Daniel
-----
Agrenon GmbH
www.agrenon.com
--
View this message in context: http://grails.1312388.n4.nabble.com/Should-save-be-transactional-by-default-Bring-back-the-DAO-tp3559922p3560175.html
Sent from the Grails - user mailing list archive at Nabble.com.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Predrag Knežević]

Hi Josh,

When I started to use Grails, it took me a while to understand that
saves/updates done in controller are not executing within a
transaction, and hence the situations you have pointed out might
happen. In order to quickly fix the legacy code we produced, I wrote a
simple plugin that adds transactional properties to controller's
actions:

http://www.grails.org/plugin/transactional-controller

Best,

Predrag

Post by basejump (Josh)
1. Should calling save on a a domain be transactional by default?
       - if not, then what is the general perspective on failed saves when cascades are in effect on associations?
       - it seems dangerous not to have the scaffolding abide by an obvious transactional pattern by default
2. Should a "DAO" pattern or "resolver" pattern be more integral to Grails.
       - it fairly hard to setup a standard transactional way of overriding persistence for a domain.
       - sure there are event, but those are not transactional and they complicate the domain.
       - once you get beyond what validation can do for you then it can become a non standard mish mash of sorts with a transactional service
3. Has anyone done any kind of work on a resolver pattern for Domains? or anything to bring back the dao?
I am trying to bring some standardization across our apps and plugins. Dejavu started to kick in. Could be habit in my design but I keep seeing the same stuff over and over.
---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email