I'm not using the SQL parts of Scaffold in new development. For new development, I'm now using Hiberate.

I'm away next week, but later this month, I'll apply some outstanding patches to Scaffold, and look at providing a direct alternative to the SQL package using either Commons SQL/Dynabeans, the new Mapping package in the Jakarta Commons sandbox, or Ibatis. There are just too many other likely alternatives now to keep this package alive.

Of course, you can always check-out the code yourself and use as part of in-house development.

The Access paradigm is not strongly linked to the StorageBeans. Essentially, it's just a facade, and you could use anything you like behind the facade. (Say Hibernate, for example.)

-Ted.

Umberto Nicoletti wrote:
I am in the middle of the process of defining the data access layer to be used for a new Struts-based application, for which we already use Scaffold's ProcessBeans.

We decided not to go with Hibernate as a persistence layer (to my disappointment) and to choose Scaffold Access/StorageBean approach instead.
Reading on this list I found an email by Ted Husted saying that he was (maybe still is?) not happy with the StorageBean deployment.


So my question is what should I do? I quite like the Scaffold data access layer and more importantly my DBA trusts it too.
I'd prefer to go with StorageBeanBase, but in this case I should make minor modifications to the Scaffold code (which I will give back to the community of course). The other option is the Access approach, but it is deprecated and it is not nice to compile an application with lots of warnings.


The modifications I have to introduce in the StorageBeanBase are:

replace all calls to

StatementUtils.executeUpdate(null,etc);

with:

StatementUtils.executeUpdate(getResource(),etc);

and add a static String resource=null; with getters and setters
that can be overriden by subclasses. This is motivated by tha fact that I have tables located in many different schemas/db hosts and want ConnectionAdaptor to return the right connection for that schema/db host.


Thank you,
Umberto


--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to