Re: [Simper] Re: Bean storage in database
Hi, Can someone explain how is Simper different from Castor (http://castor.exolab.org)? cheers, Slawek --- Bryan Field-Elliot [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Simper] Re: Bean storage in database
Hi James! -Mensaje original- De: James Strachan [mailto:[EMAIL PROTECTED]] [...] 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
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:[EMAIL PROTECTED]]
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 [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Monday, February 04, 2002 11:16 AM
Subject: RE: [Simper] Re: Bean storage in database
Hi James!
-Mensaje original-
De: James Strachan [mailto:[EMAIL PROTECTED]]
[...]
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:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[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
Re: [Simper] Re: Bean storage in database
On 2/3/02 9:57 AM, Bryan Field-Elliot [EMAIL PROTECTED] 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. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 :)
Re: Bean storage in database
Ok - Original Message - From: "Bryan Field-Elliot" [EMAIL PROTECTED] To: "Jakarta Commons Developers List" [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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" [EMAIL PROTECTED]
To: "Jakarta Commons Developers List" [EMAIL PROTECTED]
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bean storage in database
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bean storage in database
This is an interesting package. It uses the new DynaBeans from the Commons. http://netmeme.org/simper [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bean storage in database
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
