commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Weiss" <bitb...@hotmail.com>
Subject Re: Bean storage in database
Date Thu, 01 Jan 1970 00:00:00 GMT
I recently went through this little cycle with a medical project I'm 
currently on.  Without going into too much detail and boring everyone to 
tears over it, I can tell you that I started out using J2EE, simple 1.1 CMP. 
  Because 1.1 can't handle any cardinality other than 1-1 well, in places I 
needed other cardinalities I used either BMP or created XML and placed it 
into long text columns.  I am now moving my stuff over into 2.0 CMP (not a 
difficult process).

Basically, I have found that usually you will find that you need 
cardinalities other than 1-1 a lot, and simple field-to-column database 
mappings are useful for only sufficiently trivial applications.  Storing XML 
in the database is useful only if you can _guarantee_ that you wont need to 
search on that information any time in the future, otherwise you need to 
de-serialize your beans to do searching, ending up with your java engine 
doing what a database engine is designed to do.

The key here is to realize - if you are going to build a persistence engine 
other than what is currently available (CMP, or Turbine's stuff) make sure 
it is sufficiently robust, or you'll find that it isn't useful for much 
outside of textbook problems, and end up just having to port to something 
heavier later.

However, I must admit that I am an application layer partisan. <rant> I 
believe fervently that, even if EJB's are not the perfect spec, the idea of 
an application layer is exactly where the comp-sci world needs to go.  Each 
layer that we currently use (OS'es, 3 and 4GL PL's, RDBMS) abstract out a 
previous layer of difficulty, allowing the programmer to focus his aim 
higher.  I think CMP (or something like it) that allows the programmer to 
simply tell the engine that he wants the object stored, and allow the engine 
to handle the details, is the perfect next step in streamlining application 
development.  Let someone else handle the details of how to store this 
object in the most perfect manner, I'm busy with a different problem right 
now.  Whether it is EJB, or some other Application layer tech that wins out, 
I will make the prediction that in 10 years (probably more like 5) we will 
take application tiers as much for granted as we take RDBMS' and OS's today 
</rant>


>From: "Fernandez Martinez, Alejandro"  
><a.fernandez.martinez@ibermatica.com>
>Reply-To: "Jakarta Commons Developers List" 
><commons-dev@jakarta.apache.org>
>To: "Jakarta Commons Developers List (E-mail)"  
><commons-dev@jakarta.apache.org>
>Subject: Bean storage in database
>Date: Fri, 1 Feb 2002 17:44:40 +0100
>
>Hi folks!
>
>The J2EE discussion on the general list has raised some interesting
>questions. Is there any possible replacement for entity EJBs in Jakarta
>land? I'm thinking about a straight mapping from a JavaBean to a database,
>which can be useful in many simple-usage situations.
>
>The idea is: you have a bean, you want to store it in the database, every
>attribute in a field. References to included beans would be solved with
>foreign keys. A special "primary key" field is used to read it back.
>
>There are some pieces that could be used: Torque to insert XML in a
>database, and probably Digester to turn a bean into XML. But I don't know
>much about either.
>
>Is there any interest in something like this?




Omni ignotum pro magnifico - Everything unknown passes for something 
splendid

Christopher Weiss, Master of the Bit Bucket


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message