cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: DB support in flowscript (was: XSP "official" position)
Date Wed, 19 Nov 2003 18:00:56 GMT

From: Leszek Gawron

> On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote:
> > 
> > From: Leszek Gawron
> > 
> > > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote:
> > > > I really no wonder why peope still think XSP is the great
> > > Gig in the
> > > > Cocoon town, because if you google around you will feel this is 
> > > > the way Cocoon goes. To be honest I don't google about 
> this for a 
> > > > long time but still early this year this was the tendency.
> > > xsp is very powerful if you use it with esql.
> > > 
> > > - very fast custom database action creation (xsp actions)
> > > - nice syntax, no need for enormous amount of JDBC code 
> needed, no 
> > > need to
> > >   handle exceptions
> > > - esql is customized transparently for several databases (
> > > i.e.  max-rows,
> > >   skip-rows) - very useful for me because I connect 
> cocoon to existing
> > >   database installations so I do not have the comfort to 
> > > choose one that fits
> > >   the best.
> > > 
> > > while the flow:
> > > - has some database support but is really poor
> > 
> > I wouldn't code my DB support in Javascript
> I'm not advising that also. I am talking about providing an 
> easy framework for database operations that would be 
> available from flow.
> 
> 
> and really: why not ? I usually make two scripts : 
> controller.js and persistence.js. JS has a great feature: it 
> is interpreted so all you need is a text editor. You just 
> apply changes and everything works without 
> - building new classes
> - jar packaging
> - stopping the container
> - replacing the jar
> - starting the container
> 
> > 
> > > - you have to catch exceptions yourself
> > 
> > who else should catch them for you?
> SQLExceptions should be beclared or thrown. Simple JDBC 
> wrappers usually convert almost all of them to 
> RuntimeExceptions. 90% of exceptions usually denote a design 
> time or fatal error so there is really no point to recover from them
> - it just should be simply logged
> 
> > 
> > > - no database customizations
> > 
> > I think flowscript shouldn't support DB access directly
> Maybe you're right but if you drop XSP what database support 
> you have? 
> Actions? Then can be used for really simple processing as 
> using them for more advanced features makes it harder than 
> using pure JDBC.
> 
> Please note also that the biggest cocoon application example 
> - Petstore - accesses database directly from JS.
> 
> > 
> > > - O/R support is still pre-alpha and even if it was already mature
> > >   - the overhead is much too big comparing to pure JDBC 
> for projects
> > >     not-enterprise size
> > 
> > This is valid for your first project but it's like with 
> Cocoon: After 
> > your first Cocoon project many of us also take it as 
> platform for very 
> > simple projects. The last few weeks I learned more and more 
> about OJB 
> > and you can be sure I'll take it in many projects in the 
> future - also 
> > in projects where I wouldn't have taken it in the past because I 
> > *thought* it is too complicated (in opposite - using OJB 
> makes it much 
> > easier!)
> > 
> > >   - you cannot use it for web applications that use already ready 
> > > database
> > >     schema - try to add some functionality to big accounting
> > > system - you
> > >     would have to map almost whole existing db even if you 
> > > need access to 3-4
> > >     tables
> > 
> > I think if you can remove all those SQL-statements out of your code 
> > which is IMO very ugly it's worth doing it.
> 
> That's not the point - if you have an accounting system there 
> are usually about 150 tables (very large). If you implement a 
> simple plugin to that system you usually are concerned about 
> a few of them while the OJB would need to map ALL refences 
> between database tables. 
> 
> Continuing the example: cocoon is very powerful in presenting 
> reports. I haven't seen a single report tool that does O/R mapping.
> 
> Continuing II: I still cannot picture retrieving 5000 of 
> objects via O/R and showing them on paginated view - the 
> performance would be tragical.
> 
> > 
> > >   - sometimes the db schema makes it impossible to use O/R tools
> > 
> > that's possible ...
> > 
> > >   - in 2 years I haven't found a single project that does not
> > > fall under one
> > >     of above conditions
> > > 
> > > I would really like to contribute to some flow-db block that does 
> > > not involve O/R mapping but do not know where to start from.
> > > 
> > 
> > Maybe this helps - I like the idea but don't know if this will work 
> > ... but I think it worth following it. 
> > http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
> > (... but it would be OJB based)
> > 
> > What I don't want to see in a flow-db block is SQL statements ...
> I think that it should be possible to choose between O/R and 
> pure database access. O/R could be a proposed solution and 
> JDBC wrapper a backup one.


I separate between applications which are more 'publishing-centric' and
which are more 'transaction-centric'. 'publishing-centric'-applications
usually don't need flowscript. Your example (reporting tools) is of
course a representative of the this type and XSP(using ESQL) or
SQL-Transformer is the easierst way.

If you have to implement transaction logic I think there is no way
around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in
order to reach a clean design.

I think this is the message for our users.


One further thought on DB and flowscript: 
If you want to combine the ease of use of XSP and flowscript and you
don't want to mix concerns - why don't you call pipelines from within
your flowscript? 
Then you can do all the things XSP/ESQL offer having direct database
access. And I don't know how it should become easier if we build a
specif 'flow-database-framework' compared to the flexibility of Cocoon
pipelines which are called from within the flow layer. This also means
that you have caching (--> pipeline caching) for free.

--
Reinhard




Mime
View raw message