Comments on: Smooks Persistence part 1: The Introduction

By: Smies technics

Smies technics — Wed, 25 Mar 2009 15:19:53 +0000

[...] of blog posts on it on the Smooks blog. A couple of weeks ago I published the first post called “Smooks Persistence part 1: The Introduction” and today I published the second post called “Smooks Persistence part 2: How to use [...]

By: Maurice

Maurice — Mon, 02 Mar 2009 07:47:41 +0000

Thanks for your opinion Anthony. I also wanted to stay close ‘CRUD’. But instead of ‘create’ I use ‘insert’. When I would use ‘create’ it could get confusing because one could think that the entity object is created instead that the record in the db is created by inserting the entity.

By: Anthony

Anthony — Fri, 27 Feb 2009 17:39:54 +0000

insert/update/delete is really database speak.
Personally, I prefer to think of CRUD, so create/update/delete is logical for an entity.

By: Maurice

Maurice — Thu, 26 Feb 2009 22:04:33 +0000

Thanks for the good feedback Dave.

Introducing some kind of call back mechanism, for exception handling, is a great idea. I am not sure if it will make the first release, but I will see what I can do.

Regarding the Transaction handling. A visitor that can handle beginning, committing and rolling back Transactions is also on my radar. There are already visitors in the current release that can benefit from that, like for instance the SqlExecutor and JMS Router. We will probably provide that visitor in this release but surely in the next release of Smooks.

By: Dave Macpherson

Dave Macpherson — Thu, 26 Feb 2009 19:18:14 +0000

Interesting enhancement, and one I’m sure I’d be very interested in using.

I can see a whole lot of different issues one might run into while using this tho, and was wondering how you might address them. For instance, can you hook into exception processing during “inserter/updater/deleter” operations to catch potential persistence exceptions that might be thrown? If I try to persist an order and my database hiccups for some reason, am I pooched or can I try and recover (eg, try again)? This could be handled by registering a callback, for instance.

Another concern I might have is for processing huge input files….a nice feature to have would be to “batch” the commits (say, commit every N inserts). Spring batch handles this sort of “chunking”.

Just some thoughts (smile). Keep up the good work!