You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Fernandez Martinez, Alejandro" <a....@ibermatica.com> on 2002/02/01 17:44:40 UTC
Bean storage in database
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?
Re: Bean storage in database
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
FYI : I am playing devils advocate here. I think we are too loosy-goosy with
the rules when we want to be, and then appeal to the strict letter when we
want to. I think we should clean some things up - not to make *more* rules
(like we should codify the guidelines or just chuck them...) - but to make
it clear. Peter showed us things aren't clear.
Also - I have no clue what the project that we are talking about is - I was
just surprised that since it's being discussed here, and I suggested
inviting someone to work in the environs, it was rejected...
On 2/2/02 3:14 PM, "Ted Husted" <hu...@apache.org> wrote:
> We decided to create the sandbox so we wouldn't have to chase our own
> *Committers* off to Sourceforge everytime they wanted to whiteboard
> something that didn't fit in their own subprojects.
That is true, but is not the complete story.
It says that it's open to all Jakarta committers. It says nothing more than
that. Therefore, if you add someone to the Jakarta Commons Sandbox CVS,
they are in fact Jakarta committer by definition?
I hate to be a "Charter Lawyer" here, but I think that you are appealing to
letter of law, not spirit.
We created it also wanted a place to play - to play with others, to play
with new stuff, to play between projects.
All it takes is one existing jakarta committer to want to work on this, and
he can just invite Brian in, right? Are there people here who want to do
this?
>
> At the time, we specifically decided *not* to open it up to developers
> who were not already Jakarta Committers.
>
> If we are able to work with Bryan and put together a proposal for
> Simper, then we can propose it and Bryan to the Commons. But until then,
> our hands are tied.
>
Our hands are tied by what, exactly?
I can make a directory in sandbox, called 'Simper' or 'Beefcake' or 'Flying
Squirrel' and suggest that Bryan has some good ideas to develop in it...
We should make the rules clear, so our moods and feelings don¹t dictate how
we behave.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"The J2EE Compatible brand has achieved significant momentum over the past
two years, and we want to make sure that any open source efforts don't
impact the viability of that effort. "
- Karen Tegan, Director of J2EE Compatibility and Platform Services
Sun Microsystems
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Ted Husted <hu...@apache.org>.
We decided to create the sandbox so we wouldn't have to chase our own
*Committers* off to Sourceforge everytime they wanted to whiteboard
something that didn't fit in their own subprojects.
At the time, we specifically decided *not* to open it up to developers
who were not already Jakarta Committers.
If we are able to work with Bryan and put together a proposal for
Simper, then we can propose it and Bryan to the Commons. But until then,
our hands are tied.
-Ted.
"Geir Magnusson Jr." wrote:
>
> On 2/2/02 2:38 PM, "Ted Husted" <hu...@apache.org> wrote:
>
> > As much as I like Bryan, we shouldn't turn the Sandbox into a backdoor.
>
> A backdoor to what?
>
> > The Sandbox is open to all Jakarta Committers, but it should not be a
> > SourceForge for our developers.
>
> It is, actually. Take a look.
>
> >
> > So this is a case where we will have to develop the package outside
> > Jakarta, the old fashioned way, and propose it when it is ready. Then,
> > those of us who will have worked with Bryan can also vouch for him as a
> > Committer.
>
> Why?
>
> We keep *talking* about participation, expanding the community, etc, etc,
> etc.
>
> I guess I don't understand the background of the project...
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "Whoever would overthrow the liberty of a nation must begin by subduing the
> freeness of speech." - Benjamin Franklin
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/2/02 2:38 PM, "Ted Husted" <hu...@apache.org> wrote:
> As much as I like Bryan, we shouldn't turn the Sandbox into a backdoor.
A backdoor to what?
> The Sandbox is open to all Jakarta Committers, but it should not be a
> SourceForge for our developers.
It is, actually. Take a look.
>
> So this is a case where we will have to develop the package outside
> Jakarta, the old fashioned way, and propose it when it is ready. Then,
> those of us who will have worked with Bryan can also vouch for him as a
> Committer.
Why?
We keep *talking* about participation, expanding the community, etc, etc,
etc.
I guess I don't understand the background of the project...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Ted Husted <hu...@apache.org>.
As much as I like Bryan, we shouldn't turn the Sandbox into a backdoor.
The Sandbox is open to all Jakarta Committers, but it should not be a
SourceForge for our developers.
So this is a case where we will have to develop the package outside
Jakarta, the old fashioned way, and propose it when it is ready. Then,
those of us who will have worked with Bryan can also vouch for him as a
Committer.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
"Geir Magnusson Jr." wrote:
>
> On 2/2/02 2:08 PM, "Ted Husted" <hu...@apache.org> wrote:
>
> > Unfortunately, Bryan's not a Jakarta Committer right now, so we haven't
> > been able to put it in the sandbox =;o(
>
> Why not make him a committer in the sandbox?
>
> >
> > Though, I think we could induce him to get it setup a CVS someplace,
> > where we could iron out the wrinkles and put together a proposal =:o)
> >
> > I'm pretty excited about this little gem myself, but haven't had time to
> > really dig in. I am very interested in getting it up and running in some
> > things I'm working now, as soon as I get a break.
> >
> > -Ted.
> >
> >
> > James Strachan wrote:
> >>
> >> Hi Bryan
> >>
> >> Looks great stuff! Also a nice demo of Simper and Struts in action - am
> >> looking forward to seeing this in the sandbox.
> >
> > ...
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> You're going to end up getting pissed at your software
> anyway, so you might as well not pay for it. Try Open Source.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/2/02 2:08 PM, "Ted Husted" <hu...@apache.org> wrote:
> Unfortunately, Bryan's not a Jakarta Committer right now, so we haven't
> been able to put it in the sandbox =;o(
Why not make him a committer in the sandbox?
>
> Though, I think we could induce him to get it setup a CVS someplace,
> where we could iron out the wrinkles and put together a proposal =:o)
>
> I'm pretty excited about this little gem myself, but haven't had time to
> really dig in. I am very interested in getting it up and running in some
> things I'm working now, as soon as I get a break.
>
> -Ted.
>
>
> James Strachan wrote:
>>
>> Hi Bryan
>>
>> Looks great stuff! Also a nice demo of Simper and Struts in action - am
>> looking forward to seeing this in the sandbox.
>
> ...
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Ted Husted <hu...@apache.org>.
Unfortunately, Bryan's not a Jakarta Committer right now, so we haven't
been able to put it in the sandbox =;o(
Though, I think we could induce him to get it setup a CVS someplace,
where we could iron out the wrinkles and put together a proposal =:o)
I'm pretty excited about this little gem myself, but haven't had time to
really dig in. I am very interested in getting it up and running in some
things I'm working now, as soon as I get a break.
-Ted.
James Strachan wrote:
>
> Hi Bryan
>
> Looks great stuff! Also a nice demo of Simper and Struts in action - am
> looking forward to seeing this in the sandbox.
...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Simper] Re: Bean storage in database
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
It is very intersting for me, can I help ?
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, February 04, 2002 3:18 PM
Subject: Re: [Simper] Re: Bean storage in database
> On Sun, 2002-02-03 at 11:34, James Strachan wrote:
>
> Cool. BTW I could maybe help with the Digester & XML stuff if you
like.
>
>
> That would be great. Should be in the few days that I get a site up to
> support it (with CVS etc). As you might imagine, I have a "real job"
> which obviously takes precedence.
>
>
> One other thing to keep in the back of your mind when you're
> refactoring things. Once its in CVS somewhere - hopefully the sandbox
or
> failing that sourceforge - I'd be quite interested in adding support
for
> 'real' beans.
>
> I think DynaBeans are perfect for queries and for when the Java object
model
> is dictated by the database schema. Its also very common to need to
write a
> web app for an existing database, where hand coding beans to represent
the
> database is a wasted effort. Though it would be nice to support the
other
> way around as well, that Java business objects are written first and
Simper
> gets used to persist them and that the database schema comes
secondary.
>
> The Simper code is mostly based on DynaBeans and its pretty easy to
wrap a
> DynaBean around a real bean so I'm hoping that mostly Simper won't
really
> know if real or dyna beans are being used. To get the 'mark as dirty'
> features in your SimperBean we could use BCEL or JDK1.3's dynamic
proxy
> to generate wrappers that detect when bean setters are called. The
nice
> thing about this would be we could
> use Simper to persist any Java Bean, as well as DynaBeans. There's an
> object-relational can of worms that this could open but hopefully
we'll be
> able to keep it simple.
>
> That does sound interesting -- wrapping existing beans (POJO's) into
> Simper. Hopefully it can be done in a clever, yet simple way, rather
> than bloating it up into a big O/R tool. That's the mantra I hope is
> always maintained -- keep it simple yet clever. I've never worked with
> dynamic proxies, that sounds interesting.
>
>
> BTW I keep wanting to type Simpler rather than Simper. The project
name
> didn't start out as a typeo did it ;-)
>
>
> The word Simper does bounce awkwardly around the brain doesn't it? But
> it's correct -- Simple Persistence - Simper.
>
> Bryan
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Simper] Re: Bean storage in database
Posted by Bryan Field-Elliot <br...@netmeme.org>.
On Sun, 2002-02-03 at 11:34, James Strachan wrote:
Cool. BTW I could maybe help with the Digester & XML stuff if you like.
That would be great. Should be in the few days that I get a site up to
support it (with CVS etc). As you might imagine, I have a "real job"
which obviously takes precedence.
One other thing to keep in the back of your mind when you're
refactoring things. Once its in CVS somewhere - hopefully the sandbox or
failing that sourceforge - I'd be quite interested in adding support for
'real' beans.
I think DynaBeans are perfect for queries and for when the Java object model
is dictated by the database schema. Its also very common to need to write a
web app for an existing database, where hand coding beans to represent the
database is a wasted effort. Though it would be nice to support the other
way around as well, that Java business objects are written first and Simper
gets used to persist them and that the database schema comes secondary.
The Simper code is mostly based on DynaBeans and its pretty easy to wrap a
DynaBean around a real bean so I'm hoping that mostly Simper won't really
know if real or dyna beans are being used. To get the 'mark as dirty'
features in your SimperBean we could use BCEL or JDK1.3's dynamic proxy
to generate wrappers that detect when bean setters are called. The nice
thing about this would be we could
use Simper to persist any Java Bean, as well as DynaBeans. There's an
object-relational can of worms that this could open but hopefully we'll be
able to keep it simple.
That does sound interesting -- wrapping existing beans (POJO's) into
Simper. Hopefully it can be done in a clever, yet simple way, rather
than bloating it up into a big O/R tool. That's the mantra I hope is
always maintained -- keep it simple yet clever. I've never worked with
dynamic proxies, that sounds interesting.
BTW I keep wanting to type Simpler rather than Simper. The project name
didn't start out as a typeo did it ;-)
The word Simper does bounce awkwardly around the brain doesn't it? But
it's correct -- Simple Persistence - Simper.
Bryan
Re: [Simper] Re: Bean storage in database
Posted by James Strachan <ja...@yahoo.co.uk>.
Cool. BTW I could maybe help with the Digester & XML stuff if you like.
One other thing to keep in the back of your mind when you're
refactoring things. Once its in CVS somewhere - hopefully the sandbox or
failing that sourceforge - I'd be quite interested in adding support for
'real' beans.
I think DynaBeans are perfect for queries and for when the Java object model
is dictated by the database schema. Its also very common to need to write a
web app for an existing database, where hand coding beans to represent the
database is a wasted effort. Though it would be nice to support the other
way around as well, that Java business objects are written first and Simper
gets used to persist them and that the database schema comes secondary.
The Simper code is mostly based on DynaBeans and its pretty easy to wrap a
DynaBean around a real bean so I'm hoping that mostly Simper won't really
know if real or dyna beans are being used. To get the 'mark as dirty'
features in your SimperBean we could use BCEL or JDK1.3's dynamic proxy
to generate wrappers that detect when bean setters are called. The nice
thing about this would be we could
use Simper to persist any Java Bean, as well as DynaBeans. There's an
object-relational can of worms that this could open but hopefully we'll be
able to keep it simple.
BTW I keep wanting to type Simpler rather than Simper. The project name
didn't start out as a typeo did it ;-)
James
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, February 03, 2002 2:57 PM
Subject: [Simper] Re: Bean storage in database
> Hi James,
>
> Thanks for the great feedback!
>
> Yes, I identified early on that I'd like to move the initialization to
> an XML file using Digester (a tool I admittedly haven't had time to
> learn), rather than force the user to implement a Simper.IInit class.
> One possible caveat however, is that sometimes you actually have to
> write code in order to grab a DataSource from whatever connection pool
> you're using, rather than just refer to it in the XML file. However,
> careful use of adaptor classes could be thrown into the mix here (e.g. a
> class which gets the DataSource from Struts, another one which gets it
> from DBCP, etc).
>
> We are also on the same wavelength regarding the transaction
> startup/commit logic, and that it shouldn't necessarily be tied directly
> to the Servlet 2.3 Filter mechanism. I've already had an eye on
> extracting that as well into something more generic, and then providing
> an adaptor class which wraps it into a Servlet Filter. This is an easy
> one to knock off and I may do it this coming week.
>
> I'd also like to set up a CVS repository and mailing list (and a
> slightly more interesting website) this week in order to let others Ted
> really contribute. Ultimately I'd be happy to see this adopted into
> Jakarta somewhere (Commons, Sandbox, whatever), but I'm in no hurry and
> certainly don't want to cause an uproar regarding the bending of rules
> (since I'm not a committer).
>
> Thanks,
>
> Bryan
>
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Simper] Re: Bean storage in database
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/3/02 9:57 AM, "Bryan Field-Elliot" <br...@netmeme.org> wrote:
> Hi James,
>
> Thanks for the great feedback!
>
> Yes, I identified early on that I'd like to move the initialization to
> an XML file using Digester (a tool I admittedly haven't had time to
> learn), rather than force the user to implement a Simper.IInit class.
> One possible caveat however, is that sometimes you actually have to
> write code in order to grab a DataSource from whatever connection pool
> you're using, rather than just refer to it in the XML file. However,
> careful use of adaptor classes could be thrown into the mix here (e.g. a
> class which gets the DataSource from Struts, another one which gets it
> from DBCP, etc).
>
> We are also on the same wavelength regarding the transaction
> startup/commit logic, and that it shouldn't necessarily be tied directly
> to the Servlet 2.3 Filter mechanism. I've already had an eye on
> extracting that as well into something more generic, and then providing
> an adaptor class which wraps it into a Servlet Filter. This is an easy
> one to knock off and I may do it this coming week.
>
> I'd also like to set up a CVS repository and mailing list (and a
> slightly more interesting website) this week in order to let others Ted
> really contribute. Ultimately I'd be happy to see this adopted into
> Jakarta somewhere (Commons, Sandbox, whatever), but I'm in no hurry and
> certainly don't want to cause an uproar regarding the bending of rules
> (since I'm not a committer).
>
That actually remains to be explained what rules we would be bending :)
I mean, what you have is 'small' and component-like, and you appear to be
getting huge amounts of participation from here...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Simper] Re: Bean storage in database
Posted by Slawek Zachcial <sl...@yahoo.com>.
Hi,
Can someone explain how is Simper different from
Castor (http://castor.exolab.org)?
cheers,
Slawek
--- Bryan Field-Elliot <br...@netmeme.org>
wrote:
> Hi James,
>
> Thanks for the great feedback!
>
> Yes, I identified early on that I'd like to move the
> initialization to
> an XML file using Digester (a tool I admittedly
> haven't had time to
> learn), rather than force the user to implement a
> Simper.IInit class.
> One possible caveat however, is that sometimes you
> actually have to
> write code in order to grab a DataSource from
> whatever connection pool
> you're using, rather than just refer to it in the
> XML file. However,
> careful use of adaptor classes could be thrown into
> the mix here (e.g. a
> class which gets the DataSource from Struts, another
> one which gets it
> from DBCP, etc).
>
> We are also on the same wavelength regarding the
> transaction
> startup/commit logic, and that it shouldn't
> necessarily be tied directly
> to the Servlet 2.3 Filter mechanism. I've already
> had an eye on
> extracting that as well into something more generic,
> and then providing
> an adaptor class which wraps it into a Servlet
> Filter. This is an easy
> one to knock off and I may do it this coming week.
>
> I'd also like to set up a CVS repository and mailing
> list (and a
> slightly more interesting website) this week in
> order to let others Ted
> really contribute. Ultimately I'd be happy to see
> this adopted into
> Jakarta somewhere (Commons, Sandbox, whatever), but
> I'm in no hurry and
> certainly don't want to cause an uproar regarding
> the bending of rules
> (since I'm not a committer).
>
> Thanks,
>
> Bryan
>
>
>
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Simper] Re: Bean storage in database
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Hi James,
Thanks for the great feedback!
Yes, I identified early on that I'd like to move the initialization to
an XML file using Digester (a tool I admittedly haven't had time to
learn), rather than force the user to implement a Simper.IInit class.
One possible caveat however, is that sometimes you actually have to
write code in order to grab a DataSource from whatever connection pool
you're using, rather than just refer to it in the XML file. However,
careful use of adaptor classes could be thrown into the mix here (e.g. a
class which gets the DataSource from Struts, another one which gets it
from DBCP, etc).
We are also on the same wavelength regarding the transaction
startup/commit logic, and that it shouldn't necessarily be tied directly
to the Servlet 2.3 Filter mechanism. I've already had an eye on
extracting that as well into something more generic, and then providing
an adaptor class which wraps it into a Servlet Filter. This is an easy
one to knock off and I may do it this coming week.
I'd also like to set up a CVS repository and mailing list (and a
slightly more interesting website) this week in order to let others Ted
really contribute. Ultimately I'd be happy to see this adopted into
Jakarta somewhere (Commons, Sandbox, whatever), but I'm in no hurry and
certainly don't want to cause an uproar regarding the bending of rules
(since I'm not a committer).
Thanks,
Bryan
Re: Bean storage in database
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Bryan
Looks great stuff! Also a nice demo of Simper and Struts in action - am
looking forward to seeing this in the sandbox.
Funnily enough I've been meaning to post a mail for a while now to see if
anyone fancied using DynaBeans to make a lightweight SQL persistence
framework, hopefully attempting to work with the Torque folk, in particular
to reuse their SQL schema XML document and SQL DDL generation which is cool.
Their code generated 'peers' seem an alternative to DynaBeans - both have
their pros and cons - maybe they could be integrated into the same
framework?
For example on Simper you might want to reuse Torque's XML document for the
SQL schema (maybe extending it with anything else you need); then you could
write a single reusable Digester to load the tables, queries, keys,
relations into Simper and as an alternative to hand coding it in the IInit
implementation (e.g. the DemoInit class in your sample).
Then users would just need to write their single XML document to describe
their SQL tables & relations, all the DDL gets autogenerated by Torque (to
drop & recreate tables etc) and Simper would autoconfigure itself from this
document. This XML document could also be reverse engineered from an
existing database (I'm not sure if thats in Torque already).
Though take these Torque comments with a pinch of salt - I've had a look
around the code, liked what I saw, but am not coming from a Turbine
background. I guess its time for me to lurk awhile on Torque's list... ;-)
James
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, February 02, 2002 3:54 PM
Subject: Re: Bean storage in database
> Hi Juozas,
>
> Before starting your project this weekend, I recommend you have a look
> at my Simper framework, which does roughly what you describe already.
> I'm in the process of working with Ted Husted to get it submitted into
> the sandbox here. In the meantime, take a look at:
>
> http://www.netmeme.org/simper
>
> Feature highlights include:
> - Wrapping of table rows using the new DynaBean
> - Automatic change detection and writing back to database, like EJB CMP
> - Automatic use of Servlet 2.3 filters to demark transactions (also like
> EJB entity beans)
> - Support for relations between table, in a querying capacity (not
> cascading updates or deletes)
> - < 1,500 lines of code - simple to understand, yet packs a punch
> - README describes rationale behind it's design and the tradeoffs made
> (coming from an EJB CMP perspective)
>
> Thanks,
>
> Bryan
>
>
> On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
>
> Hi,
> this work will be started today. It will be simplestore samples.
> I will try to clear my code, it is very dirty and have a lot of bugs
at
> this time.
> I decided to implement this for my current project, but I see it can
be
> useful in some more common situations.
> I think it is more example for simplestore usage, not any kind of
framework.
> It will be very limited, but it always possible to enhance. I will use
this
> for "readonly" data.
> like :
> CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
> COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
> ...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY
. )
> I have plans to support "Stored Procedures" , Transactions,
> Finders, Relations .......... .
> But it is not very trivial to implement this stuff on this weekend :)
>
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Juozas Baliuka <ba...@mwm.lt>.
Ok
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, February 02, 2002 4:54 PM
Subject: Re: Bean storage in database
> Hi Juozas,
>
> Before starting your project this weekend, I recommend you have a look
> at my Simper framework, which does roughly what you describe already.
> I'm in the process of working with Ted Husted to get it submitted into
> the sandbox here. In the meantime, take a look at:
>
> http://www.netmeme.org/simper
>
> Feature highlights include:
> - Wrapping of table rows using the new DynaBean
> - Automatic change detection and writing back to database, like EJB CMP
> - Automatic use of Servlet 2.3 filters to demark transactions (also like
> EJB entity beans)
> - Support for relations between table, in a querying capacity (not
> cascading updates or deletes)
> - < 1,500 lines of code - simple to understand, yet packs a punch
> - README describes rationale behind it's design and the tradeoffs made
> (coming from an EJB CMP perspective)
>
> Thanks,
>
> Bryan
>
>
> On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
>
> Hi,
> this work will be started today. It will be simplestore samples.
> I will try to clear my code, it is very dirty and have a lot of bugs
at
> this time.
> I decided to implement this for my current project, but I see it can
be
> useful in some more common situations.
> I think it is more example for simplestore usage, not any kind of
framework.
> It will be very limited, but it always possible to enhance. I will use
this
> for "readonly" data.
> like :
> CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
> COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
> ...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY
. )
> I have plans to support "Stored Procedures" , Transactions,
> Finders, Relations .......... .
> But it is not very trivial to implement this stuff on this weekend :)
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Simper] adding a transaction API (was Re: Bean storage in database)
Posted by James Strachan <ja...@yahoo.co.uk>.
Bryan
Another thought on Simper. It'd be nice to add an explicit transaction API
to Simper, then when needed transactional units of database code could be
done using code similar to Juozas' example. This would allow Simper to work
outside of Servlets or on pre 2.3 Servlet engines - or allow more complex
transactional units to be done such as committing small units of work as you
go rather than doing it all in one batch at the end of a HTTP request.
e.g. some code might try to commit changes to the database, if they fail,
rollback then do something else (which might involve some other database
commits.
It doesn't have to be anything grand. Something simple like
simper.begin(); // (*)
SimperBean newAuthor = simper.create("authors");
// Set some properties
newAuthor.set("name", name);
newAuthor.set("email", email);
simper.commit();
The only issue to be careful of is threading, though it appears from the
Simpler code that everythings nicely ThreadLocal'd anyways so it should work
a treat.
Its essentially just moving the existing 'transaction' code into a
transaction API in the Simper class then moving the Servlet Filter to a new
class (SimperServletFilter) which would just call the transaction API. This
also removes the direct dependency of Simper on Servlet 2.3 as
SimperServletFilter becomes an optional utility class - developers could
always explicitly scope their transactions without needing Servlet Filters.
(*) the begin() method might well be redundant, commit() and rollback()
might just do it.
James
----- Original Message -----
From: "Juozas Baliuka" <ba...@mwm.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, February 02, 2002 5:50 PM
Subject: Re: Bean storage in database
> Hi,
> Yes simpler is good idea, I think abaut the same. Example in simplestore
> uses the same ideas.
> Implementation looks some diferent, but I think we can work together , I
> have the same ideas about transactions, "Value Objects" .... .
>
> Fragment from simpler usage :
> SimperBean newAuthor = simper.create("authors");
> // Set some properties (this works the same whether creating new rows
or
> editing existing ones)
> newAuthor.set("name", name);
> newAuthor.set("email", email);
> // Save a message for the JSP page, and show a JSP page
>
> Fragment from simplestore example test:
>
> TestPersistence testObject;//only interface types supported at
> this time
> Transaction t = pm.getTransaction();
> t.begin();
> testObject =
> (TestPersistence)pm.createInstance(TestPersistence.class);
> testObject.setBoolVal(true);
> testObject.setIntVal(777);
> assertEquals(testObject.getIntVal(),777);
> testObject.setStrVal("TEST");
> testObject.setDateVal(new java.util.Date());
> testObject.setFloatVal(3f);
> t.commit();
>
>
> ----- Original Message -----
> From: "Bryan Field-Elliot" <br...@netmeme.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, February 02, 2002 4:54 PM
> Subject: Re: Bean storage in database
>
>
>
>
> > Hi Juozas,
> >
> > Before starting your project this weekend, I recommend you have a look
> > at my Simper framework, which does roughly what you describe already.
> > I'm in the process of working with Ted Husted to get it submitted into
> > the sandbox here. In the meantime, take a look at:
> >
> > http://www.netmeme.org/simper
> >
> > Feature highlights include:
> > - Wrapping of table rows using the new DynaBean
> > - Automatic change detection and writing back to database, like EJB CMP
> > - Automatic use of Servlet 2.3 filters to demark transactions (also like
> > EJB entity beans)
> > - Support for relations between table, in a querying capacity (not
> > cascading updates or deletes)
> > - < 1,500 lines of code - simple to understand, yet packs a punch
> > - README describes rationale behind it's design and the tradeoffs made
> > (coming from an EJB CMP perspective)
> >
> > Thanks,
> >
> > Bryan
> >
> >
> > On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
> >
> > Hi,
> > this work will be started today. It will be simplestore samples.
> > I will try to clear my code, it is very dirty and have a lot of bugs
> at
> > this time.
> > I decided to implement this for my current project, but I see it can
> be
> > useful in some more common situations.
> > I think it is more example for simplestore usage, not any kind of
> framework.
> > It will be very limited, but it always possible to enhance. I will
use
> this
> > for "readonly" data.
> > like :
> > CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
> > COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
> > ...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY
> . )
> > I have plans to support "Stored Procedures" , Transactions,
> > Finders, Relations .......... .
> > But it is not very trivial to implement this stuff on this weekend
:)
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bean storage in database
Posted by Paulo Gaspar <pa...@krankikom.de>.
I think that having every other class implementing setXxxxVal() methods
where Xxxx is a type is dreadful.
Are you sure you have to do it like that?
Couldn't you just have a set(Object val) method and an utility class?
I have an utility class (can contribute) for those usual conversions that
goes like this:
public class CvtHelper
{
private final Converter m_converter;
public CvtHelper(final Converter i_converter)
{
m_converter = i_converter;
}
public final Object get(final Class i_destClass, final Object i_value)
{
return m_converter.converted(i_destClass, i_value);
}
public final Object get(final Class i_destClass, final Object i_value,
final Object i_default)
{
final Object res = get(i_destClass, i_value);
return (null != res) ? res : i_default;
}
public final Boolean getBoolean(final Object i_value)
{
return (Boolean)get(java.lang.Boolean.class, i_value);
}
public final Boolean getBoolean(final Object i_value, final Boolean
i_defaultValue)
...
public final boolean getBoolean(final Object i_value, final boolean
i_defaultValue)
...
public final Byte getByte(final Object i_value)
...
public final Byte getByte(final Object i_value, final Byte
i_defaultValue)
...
public final byte getByte(final Object i_value, final byte
i_defaultValue)
...
}
It uses a Converter class just as I described during the DynaBean
discussion and avoids having every other class cluttered with a bunch
of getXxxx() or setXxxx() methods.
What do you think?
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Juozas Baliuka [mailto:baliuka@mwm.lt]
> Sent: Saturday, February 02, 2002 6:51 PM
> To: Jakarta Commons Developers List
> Subject: Re: Bean storage in database
>
>
> Hi,
> Yes simpler is good idea, I think abaut the same. Example in simplestore
> uses the same ideas.
> Implementation looks some diferent, but I think we can work together , I
> have the same ideas about transactions, "Value Objects" .... .
>
> Fragment from simpler usage :
> SimperBean newAuthor = simper.create("authors");
> // Set some properties (this works the same whether creating
> new rows or
> editing existing ones)
> newAuthor.set("name", name);
> newAuthor.set("email", email);
> // Save a message for the JSP page, and show a JSP page
>
> Fragment from simplestore example test:
>
> TestPersistence testObject;//only interface types supported at
> this time
> Transaction t = pm.getTransaction();
> t.begin();
> testObject =
> (TestPersistence)pm.createInstance(TestPersistence.class);
> testObject.setBoolVal(true);
> testObject.setIntVal(777);
> assertEquals(testObject.getIntVal(),777);
> testObject.setStrVal("TEST");
> testObject.setDateVal(new java.util.Date());
> testObject.setFloatVal(3f);
> t.commit();
>
>
> ----- Original Message -----
> From: "Bryan Field-Elliot" <br...@netmeme.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, February 02, 2002 4:54 PM
> Subject: Re: Bean storage in database
>
>
>
>
> > Hi Juozas,
> >
> > Before starting your project this weekend, I recommend you have a look
> > at my Simper framework, which does roughly what you describe already.
> > I'm in the process of working with Ted Husted to get it submitted into
> > the sandbox here. In the meantime, take a look at:
> >
> > http://www.netmeme.org/simper
> >
> > Feature highlights include:
> > - Wrapping of table rows using the new DynaBean
> > - Automatic change detection and writing back to database, like EJB CMP
> > - Automatic use of Servlet 2.3 filters to demark transactions (also like
> > EJB entity beans)
> > - Support for relations between table, in a querying capacity (not
> > cascading updates or deletes)
> > - < 1,500 lines of code - simple to understand, yet packs a punch
> > - README describes rationale behind it's design and the tradeoffs made
> > (coming from an EJB CMP perspective)
> >
> > Thanks,
> >
> > Bryan
> >
> >
> > On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
> >
> > Hi,
> > this work will be started today. It will be simplestore samples.
> > I will try to clear my code, it is very dirty and have a lot of bugs
> at
> > this time.
> > I decided to implement this for my current project, but I see it can
> be
> > useful in some more common situations.
> > I think it is more example for simplestore usage, not any kind of
> framework.
> > It will be very limited, but it always possible to enhance.
> I will use
> this
> > for "readonly" data.
> > like :
> > CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
> > COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
> > ...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY
> . )
> > I have plans to support "Stored Procedures" , Transactions,
> > Finders, Relations .......... .
> > But it is not very trivial to implement this stuff on this
> weekend :)
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
Yes simpler is good idea, I think abaut the same. Example in simplestore
uses the same ideas.
Implementation looks some diferent, but I think we can work together , I
have the same ideas about transactions, "Value Objects" .... .
Fragment from simpler usage :
SimperBean newAuthor = simper.create("authors");
// Set some properties (this works the same whether creating new rows or
editing existing ones)
newAuthor.set("name", name);
newAuthor.set("email", email);
// Save a message for the JSP page, and show a JSP page
Fragment from simplestore example test:
TestPersistence testObject;//only interface types supported at
this time
Transaction t = pm.getTransaction();
t.begin();
testObject =
(TestPersistence)pm.createInstance(TestPersistence.class);
testObject.setBoolVal(true);
testObject.setIntVal(777);
assertEquals(testObject.getIntVal(),777);
testObject.setStrVal("TEST");
testObject.setDateVal(new java.util.Date());
testObject.setFloatVal(3f);
t.commit();
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, February 02, 2002 4:54 PM
Subject: Re: Bean storage in database
> Hi Juozas,
>
> Before starting your project this weekend, I recommend you have a look
> at my Simper framework, which does roughly what you describe already.
> I'm in the process of working with Ted Husted to get it submitted into
> the sandbox here. In the meantime, take a look at:
>
> http://www.netmeme.org/simper
>
> Feature highlights include:
> - Wrapping of table rows using the new DynaBean
> - Automatic change detection and writing back to database, like EJB CMP
> - Automatic use of Servlet 2.3 filters to demark transactions (also like
> EJB entity beans)
> - Support for relations between table, in a querying capacity (not
> cascading updates or deletes)
> - < 1,500 lines of code - simple to understand, yet packs a punch
> - README describes rationale behind it's design and the tradeoffs made
> (coming from an EJB CMP perspective)
>
> Thanks,
>
> Bryan
>
>
> On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
>
> Hi,
> this work will be started today. It will be simplestore samples.
> I will try to clear my code, it is very dirty and have a lot of bugs
at
> this time.
> I decided to implement this for my current project, but I see it can
be
> useful in some more common situations.
> I think it is more example for simplestore usage, not any kind of
framework.
> It will be very limited, but it always possible to enhance. I will use
this
> for "readonly" data.
> like :
> CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
> COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
> ...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY
. )
> I have plans to support "Stored Procedures" , Transactions,
> Finders, Relations .......... .
> But it is not very trivial to implement this stuff on this weekend :)
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Hi Juozas,
Before starting your project this weekend, I recommend you have a look
at my Simper framework, which does roughly what you describe already.
I'm in the process of working with Ted Husted to get it submitted into
the sandbox here. In the meantime, take a look at:
http://www.netmeme.org/simper
Feature highlights include:
- Wrapping of table rows using the new DynaBean
- Automatic change detection and writing back to database, like EJB CMP
- Automatic use of Servlet 2.3 filters to demark transactions (also like
EJB entity beans)
- Support for relations between table, in a querying capacity (not
cascading updates or deletes)
- < 1,500 lines of code - simple to understand, yet packs a punch
- README describes rationale behind it's design and the tradeoffs made
(coming from an EJB CMP perspective)
Thanks,
Bryan
On Sat, 2002-02-02 at 02:03, Juozas Baliuka wrote:
Hi,
this work will be started today. It will be simplestore samples.
I will try to clear my code, it is very dirty and have a lot of bugs at
this time.
I decided to implement this for my current project, but I see it can be
useful in some more common situations.
I think it is more example for simplestore usage, not any kind of framework.
It will be very limited, but it always possible to enhance. I will use this
for "readonly" data.
like :
CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY .... )
I have plans to support "Stored Procedures" , Transactions,
Finders, Relations .......... .
But it is not very trivial to implement this stuff on this weekend :)
Re: Bean storage in database
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
this work will be started today. It will be simplestore samples.
I will try to clear my code, it is very dirty and have a lot of bugs at
this time.
I decided to implement this for my current project, but I see it can be
useful in some more common situations.
I think it is more example for simplestore usage, not any kind of framework.
It will be very limited, but it always possible to enhance. I will use this
for "readonly" data.
like :
CREATE VIEW MY_STAT AS ( SELECT ID, SUM( SOMETHING ) ,
COUNT(SOMETHING), MAX(SOMETHING) FROM MY_TABLE,
...... WHERE ........ GROUP BY ID HAVING ..... ORDER BY .... )
I have plans to support "Stored Procedures" , Transactions,
Finders, Relations .......... .
But it is not very trivial to implement this stuff on this weekend :)
At 05:44 PM 2/1/2002 +0100, you wrote:
>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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by Ted Husted <hu...@apache.org>.
This is an interesting package. It uses the new DynaBeans from the
Commons.
http://netmeme.org/simper
bayard@generationjava.com wrote:
>
> objectbridge.sourceforge.net does something like that.
>
> It looked pretty good when I looked at it and I plan to try and integrate
> it into a project soon instead of using the relatively useless EJB :)
>
> Bay
>
> On Fri, 1 Feb 2002, Fernandez Martinez, Alejandro wrote:
>
> > 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?
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bean storage in database
Posted by ba...@generationjava.com.
objectbridge.sourceforge.net does something like that.
It looked pretty good when I looked at it and I plan to try and integrate
it into a project soon instead of using the relatively useless EJB :)
Bay
On Fri, 1 Feb 2002, Fernandez Martinez, Alejandro wrote:
> 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?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>