commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [Simper] Re: Bean storage in database
Date Tue, 05 Feb 2002 10:20:02 GMT
I don't know, is very good idea to have this kind of code in simplestore,
don't forget this code is very crapy and can't be used in production at this
time.
It seems it works, but it will not work in realistic situation. I will need
a few days
to make it working.
----- Original Message -----
From: "Gerhard Froehlich" <g-froehlich@gmx.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, February 04, 2002 8:26 PM
Subject: RE: [Simper] Re: Bean storage in database


> Hi,
>
> Shall I commit that for you into the simplestore
> package?
>
> I guess I should ;)
>
>   ~Gerhard
>
> "Whose cruel idea was it for the word "lisp" to have an "s" in it?"
>
>
> >-----Original Message-----
> >From: Juozas Baliuka [mailto:baliuka@mwm.lt]
> >Sent: Monday, February 04, 2002 1:25 PM
> >To: Jakarta Commons Developers List
> >Subject: Re: [Simper] Re: Bean storage in database
> >
> >
> >Hi,
> >I have "bad karma" to commit something. I will send this example to list.
> >It is very trivial example for simplestore. It is possible to start some
> >persitence implementation form this example. Don't waste time to test it,
it
> >will not work in most
> >of situations. But ideas can be useful. Ideas are from JDO, it is nothing
> >new, just example for simplestore.
> >
> >it is fragment from test, it works, but I know situations then it will
not
> >work :
> >
> > public void testCreateInstance() {
> >        try{
> >            Object oid;
> >            TestPersistence testObject;
> >            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();
> >            System.out.println("Begin Transaction");
> >            t.begin();
> >            oid = pm.getOID(testObject);
> >            long time = System.currentTimeMillis();
> >            int i = 0;
> >            TestPersistence testObject1 = null;
> >            for(; i < 100; ++i ){
> >                testObject1 = (TestPersistence)
> >pm.findInstance(TestPersistence.class,oid);
> >            }
> >            System.out.println("Retrueved " + i + " Objects " +
> > System.currentTimeMillis() - time)/1000 + " s");
> >
> >            testObject1.setStrVal("TEST1");
> >            t.commit();
> >            assertEquals("retrieved by id ",testObject,testObject1);
> >            assertEquals("int val
> >",testObject.getIntVal(),testObject1.getIntVal());
> >
> >        }catch(Exception e){
> >            e.printStackTrace();
> >            fail( e.getMessage() );
> >        }
> >    }
> >
> >
> >----- Original Message -----
> >From: "Fernandez Martinez, Alejandro"
<a.fernandez.martinez@ibermatica.com>
> >To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
> >Sent: Monday, February 04, 2002 11:16 AM
> >Subject: RE: [Simper] Re: Bean storage in database
> >
> >
> >> Hi James!
> >>
> >> > -----Mensaje original-----
> >> > De: James Strachan [mailto:james_strachan@yahoo.co.uk]
> >>
> >> [...]
> >>
> >> > 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.
> >>
> >> Yes, I also think that coding beans is better than writing XML files.
My
> >> original query was along these lines.
> >>
> >> If you remove a field from a bean and keep using it elsewhere, the
> >compiler
> >> will tell you; but if you delete a field from the config file and keep
> >using
> >> it, you get an exception at runtime.
> >>
> >> That has been my experience: it's better to have strongly typed
attributes
> >> than an abstract database layer.
> >>
> >> Now, if we can have both, it would be great.
> >>
> >> Un saludo,
> >>
> >> Alex.
> >>
> >> > 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
> >>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


--
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