cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Cocoon + database best practice?
Date Thu, 10 Feb 2005 22:37:35 GMT
On Jue, 10 de Febrero de 2005, 11:30, WHIRLYCOTT dijo:
> My view on this particular matter may go against the grain here, but I
> think that both the modular db actions and the sql transformers should
> not, in general, be used.
> Your work with the modular db actions and the sql transformer will not
> be portable since they are tightly coupled to Cocoon.  This is going to
> limit you at some point when you want to write some junit tests or
> command line apps.

I agree. Now (in 2005 at our current level) there is no good idea to use
them at all.

> Furthermore, I've found that both the sql transformer and the modular db
> actions are fairly buggy and quite incomplete in what they offer.  Try
> doing some complex stuff with multiple queries and transactions to see
> what I mean.

Don't agree. It is posible to do with them a lot of work. They are stable
and not buggy. The reasons to I don't recommend them is because the
maintenance of the system is more complicated. That is all! With O/R
mapping it is more easy the later maintenance work.

For the records, in mid-2003, we developed a payroll system using Modular
DB Actions.

The system was developed for a company that sells payroll services to
other companies or corporations. We need to keep track on the system about
all the operations of this company.

Under some circunstances the system needs to mix some companies. In some
cases there is people with a high rotation (some times a person is hired
and fired more than 5 times monthly) and other cool things. The system
allow a lot of flexibility for our Nicaraguan laws. And I am talking about
our laws, because for sure, were done without a computer in mind.

And I can tell that Modular DB actions pretty good managed the system. In
fact we just found 1 or 2 cases where was imposible to use Modular or
Original DB Actions. In the system we complemented with stored procedures
and java some business logic. The database was of course PostgreSQL. Some
statistics: 44 tables, 197 stored procedures, 22 sequences and 6 views.

This is why I think we cannot tell that they are buggy and unstable. In
fact we started to develop the system with Cocoon 2.1.0 and it was worked
in all versions even today in the lastest 2.1.7-dev on the current SVN.
Without changing a line of code while migrating between cocoon versions!

> More importantly: Hibernate, OJB, or JDO are much more compelling.
> You'll be several times more productive using one of these than you will
> by hand-coding sql, mapping resultset data back and forth, etc.  These
> ought to be wrapped in a facade and exposed to your application that way
> rather than intersprinkling lots of sql stuff throughout your sitemap.


Best Regards,

Antonio Gallardo

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message