Re: Struts DB Access :: Best Practices
On Wed, 09 Mar 2005 15:48:52 -0600, Scott Lamb [EMAIL PROTECTED] wrote: karthikeyan balasubramanian wrote: I looked at iBATIS, it seems to be simple and easy to use. I will also check out others and let you know my thoughts. I'll add one to your list: Axamol SQL Library http://www.slamb.org/projects/axamol/sql-library/ It's a project of mine, so I'd love to hear if it works out for you. (Or if it doesn't do what you need, but could if I added feature X.) It is similar to iBATIS SQL Maps but lighter / narrower in scope. I looked over their user manual recently, and the differences I spotted were: Disclosure: I am an iBATIS developer, so I'd like to offer another opinion on the comparison. :-) - iBATIS does database pooling for you; Axamol does not. I prefer to use the servlet container's built-in pooling. What about testing your DAOs? The dependency on the servlet container can become problematic. - iBATIS does caching; Axamol does not. I haven't encountered the situation in which I'd want quite the caching they have. I work with iBATIS on a project where I regularly do queries over multi-gigabyte tables. Caching is darn handy in those situations. :-) - iBATIS has a lot of options to use JavaBeans, which I don't find useful. I just take parameters in a java.util.Map and return a java.sql.ResultSet directly. (I'm a DynaActionForm kind of guy, so using a form bean form this would be a little out of place.) OK, now I have to just plain disagree with you. ;-) Using Maps and ResultSet in your application as the domain model is just plain bad design. It is difficult to test and too loosely coupled. I am sure Vic will disagree with me if he's reading this. :-P - iBATIS has a lot of support for translating magic values (of the 9/9/99 variety) into nulls, which is a fundamentally bad idea. Axamol doesn't do this and never will. Hmm, I tend to agree that this is a bad idea. I avoid that, too. - iBATIS's conditional SQL elements have this prepend=... attribute that I find confusing. I accomplish the same thing just by using boolean identities: true and boolvar = false or boolvar = boolvar. Compare the example on iBATIS SQL Map's developer guide page 35 to my example two at http://www.slamb.org/projects/axamol/sql-library/manual/pr01s02.html and you'll see what I'm getting at. That is an interesting approach. Very simple. I have yet to see a clean way of dealing with this problem. IMO, no SQL framework feels quite right for this stuff. When I was coding SQL directly in Java, I did it the way you describe. - Axamol includes XSLT and standardized elements for embedding documentation in your libraries and producing HTML for them. Cool! I have wondered if including that in iBATIS would be used. Do your users use that much? - Axamol captures timing statistics which are useful for determining where you need to optimize your SQL. That is a nice feature, and I think it would be easy to add to iBATIS...maybe in the next version. A few other things I did not see in Axamol: - row handlers - consistent dynamic sql (from what I see, there are different ways for altering the order and the where clauses..are there others?) The binding looks more awkward to me: iBATIS - select * from someTable where key = #id# axamol - select * from someTable where key = s:bind param=id/ With many parameters, this would get really noisy IMO. I like how you handle multiple databases. Simple. Good job on that. Cool project Scott, I hope you are not offended if we take some of your ideas for iBATIS. ;-) Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
I agree with Rick. SQL has been around for years and years. IMO, it will outlive most languages we are writing with today because of its wide acceptance. Before using iBATIS, I used Hibernate. In my experience with it, it made the simple things simple, and the difficult things all but impossible. Performance was also an issue in my case (multi-gigabyte legacy tables do not lend themselves to Hibernate very well). Larry On Wed, 09 Mar 2005 17:19:17 -0500, Rick Reumann [EMAIL PROTECTED] wrote: Jesse Clark wrote the following on 3/9/2005 4:46 PM: However, I would disagree with your earlier comment that Hibernate is very easy to learn. It is a powerful tool and makes life easier once you learn it, but I think realistically you are looking at a 3 to 6 week learning curve to really figure out how everything fits together and develop a working architecture. I'd even disagree that it makes things easier once you learn it. I'd say only sometimes. It often creates a lot of headaches and you'll definitely run into difficulties if you don't own the tables and you can't create the table structure the way you want it. On the other hand, plugging iBATIS again, iBATIS doesn't care what the table structure is like. One of the great things about iBATIS is that as a developer I can get a nice optimized piece of pure SQL from a DBA using existing tables and can use that exact query/update in iBATIS (no need to even learn another query language either). I think it's great having competing frameworks. Only makes all of them better. Personally I find iBATIS simple and powerful. I also have to say that I think all the apparent buzz around Hibernate is based purely on politics (Same thing with Spring.) Not saying both aren't solid products, but they are often pushed in the same breath at conferences etc without even considering alternatives that might be better and/or easier to use. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Hi karthikeyan, Stick with SQL based persistent frameworks like iBATIS. The learning curve is minimal, expertise is easily available and your application will stand the test of time. Relational databases and SQL are'nt going away any time soon. OR mapping tools are like EJBs, full of hype. They sound good in theory, suck big time in practice. - Original Message - From: karthikeyan balasubramanian [EMAIL PROTECTED] To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Date: Wed, 9 Mar 2005 13:49:03 +0530 Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Antony Joseph http://www.logicden.com https://workeffort.dev.java.net -- ___ NEW! Lycos Dating Search. The only place to search multiple dating sites at once. http://datingsearch.lycos.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Larry Meadors wrote: - iBATIS has a lot of options to use JavaBeans, which I don't find useful. I just take parameters in a java.util.Map and return a java.sql.ResultSet directly. (I'm a DynaActionForm kind of guy, so using a form bean form this would be a little out of place.) OK, now I have to just plain disagree with you. ;-) Using Maps and ResultSet in your application as the domain model is just plain bad design. It is difficult to test and too loosely coupled. I am sure Vic will disagree with me if he's reading this. :-P I missed the bait! So I used to do all the trick with beans, even named my company BaseBeans (there are so many benefits- I think I know them all)... and I was pushin limits of beans, I even did not like and still don't DynaBeans. One the 1up project, I was horrified to see mutiple beans, such as UserBeansX and ContentBeansY; and some were deprecated and all had get/sets that were not being used. Also I was doing ActionScript and looking at other dynamic langs, where they used AssoicativeArrays. And I took a big liking to dynamic nature, ex Grovy. The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA. Wherever I used to use a bean, now I use a collection, and I like DynaMaps. maybe one day you guys catch up;-) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
Vic writes: :snip: The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA. Wherever I used to use a bean, now I use a collection, and I like DynaMaps. maybe one day you guys catch up;-) I think I'm buying what you say in a big kinda way. I've been there already I think, but forcing myself to use the DynaBean route and if you've read my posts here, you know I'm frustrated. I've been coming to your conclusion, and I'd love to hear more from you offline if you don't mind. I disagree vehemently that the idea of Maps in the Domain Model is a bad design. I worked for years in an architecture that eschewed many OO concepts as creating more work than they saved. Its universe was something like this- A Database contains a map of Table Objects A Table object contains an array list of Record Objects. A Record object contains a map of Field Objects. Etc Done properly, something like this could be infinitely reusable no matter what the application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
Vic writes: :snip: The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA. Wherever I used to use a bean, now I use a collection, and I like DynaMaps. maybe one day you guys catch up;-) I think I'm buying what you say in a big kinda way. I've been there already I think, but forcing myself to use the DynaBean route and if you've read my posts here, you know I'm frustrated. I've been coming to your conclusion, and I'd love to hear more from you offline if you don't mind. I disagree vehemently that the idea of Maps in the Domain Model is a bad design. I worked for years in an architecture that eschewed many OO concepts as creating more work than they saved. Its universe was something like this- A Database contains a map of Table Objects A Table object contains an array list of Record Objects. A Record object contains a map of Field Objects. Etc Done properly, something like this could be infinitely reusable no matter what the application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
On 10 Mar 2005, at 07:59, Larry Meadors wrote: Disclosure: I am an iBATIS developer, so I'd like to offer another opinion on the comparison. Cool! I might add an appendix to my documentation with this comparison. When I do, I'll give you another opportunity to complain. :) - iBATIS does database pooling for you; Axamol does not. I prefer to use the servlet container's built-in pooling. What about testing your DAOs? The dependency on the servlet container can become problematic. The client code is expected to pass in a java.sql.Connection or javax.sql.DataSource, so there's no direct dependency. - iBATIS does caching; Axamol does not. I haven't encountered the situation in which I'd want quite the caching they have. I work with iBATIS on a project where I regularly do queries over multi-gigabyte tables. Caching is darn handy in those situations. :-) I'm sure it is there. But I don't need it yet, and no one's complained to me that they do, either. I deliberately avoid writing features before they're needed. - iBATIS has a lot of options to use JavaBeans, which I don't find useful. I just take parameters in a java.util.Map and return a java.sql.ResultSet directly. (I'm a DynaActionForm kind of guy, so using a form bean form this would be a little out of place.) OK, now I have to just plain disagree with you. ;-) Using Maps and ResultSet in your application as the domain model is just plain bad design. It is difficult to test and too loosely coupled. I used to be of this school of thought also. But, well, then I encountered Python. ;) I'd like to do things statically, but not at the expense of writing lots of code. I particularly hate code initially generated by tools that I have to manually maintain afterward. And besides, everything else in a servlet container takes this approach - context, session, request, and page scope variables are all essentially map entries. - Axamol includes XSLT and standardized elements for embedding documentation in your libraries and producing HTML for them. Cool! I have wondered if including that in iBATIS would be used. Do your users use that much? What users? ;) Axamol SQL Library doesn't have the community iBATIS does. I use it, a friend uses it, and I've gotten a fair number of downloads. But my projects can be weird that way...even with NetGrowler, which _must_ be popular (lots of downloads, I see occasional mentions of it on forums), I only hear from users when they've got a problem or feature request. So I don't know how many users I have, much less exactly what parts of it they use. But my friend and I find it useful. A few other things I did not see in Axamol: - row handlers I'm not sure what you mean by this: - The things for grabbing a a single int value and such when you do count(*), rather than dealing with the whole ResultSet? I've thought about adding those, but for now Axamol SQL Library is dirt-simple: it just always gives you the ResultSet. - The things for linking to other queries on a per-row basis? I try to avoid those; I like my pages to make a constant number of queries. - consistent dynamic sql (from what I see, there are different ways for altering the order and the where clauses..are there others?) There's also the s:bindlist/, which is similar to your iterator. The binding looks more awkward to me: iBATIS - select * from someTable where key = #id# axamol - select * from someTable where key = s:bind param=id/ It is. I did it this way initially to avoid having to do any parsing; just for ease of implementation. I might end up introducing a syntax like that. I like how you handle multiple databases. Simple. Good job on that. Thanks. Cool project Scott, I hope you are not offended if we take some of your ideas for iBATIS. ;-) I'd be flattered. Larry Regards, Scott -- Scott Lamb http://www.slamb.org/ PGP.sig Description: This is a digitally signed message part
Re: Struts DB Access :: Best Practices
Joe Hertz wrote: The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA. Wherever I used to use a bean, now I use a collection, and I like DynaMaps. I think I'm buying what you say in a big kinda way. Cool. I worked for years in an architecture that eschewed many OO concepts as creating more work than they saved. I of course see a lot of productivity and velocity (rate of development) of useing OO w/ Collections. You can have BaseMap or BaseList, etc. Its universe was something like this- A Database contains a map of Table Objects A Table object contains an array list of Record Objects. A Record object contains a map of Field Objects. Etc Even silly JSF uses RowSet as DTO. (RowSet is realy a ArrayList of HashMaps. Rows of Columns) I look at it like this: -SQL is a Set oriented lang.(row by row processing is exponentialy slower) -iBatis can allways return an ArrayList of Hashmaps (so I do not have to write a bean, or keep the bean up to date w/ my Domain - I consider iBatis a domain). - Flex (RiA) can recive a ArrayList of HashMap as natie Associative Array. (so cool that Collection is a DTO - I can even change form model w/o creating new beans or new gets/sets) - Since this design works w/ Flex, I might as well use it in JDNC. Or the short version: In Java, we represent Sets as/is a Collection. For Struts, that means not a FormBean, but a FormModel (a map that maps to fields). No more mutiple CustomerBeans on large projects and having to add get/set when view or domain evolves. It's dynamic and losly coupled. I am not sure if I am advocating not mastering beans 1st, what with late binding issues they solve. But once you know beans, then... dynamic. hth, .V Done properly, something like this could be infinitely reusable no matter what the application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
Along those lines, I've added an entry to the iBatis Wiki (http://wiki.apache.org/ibatis/). Select 3rd Party Contributions and review the section Convert ResultSet to JSTL Result. You can think of JSTL's Result interface as something *similar* to JDBC's CachedRowSet and BeanUtils' RowSetDynaClass. The example is slanted towards handling cursors that are output parameters from stored procedures, but the basic idea can applied anywhere you want to extract data from a ResultSet. Quoting Joe Hertz [EMAIL PROTECTED]: Vic writes: :snip: The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA. Wherever I used to use a bean, now I use a collection, and I like DynaMaps. maybe one day you guys catch up;-) I think I'm buying what you say in a big kinda way. I've been there already I think, but forcing myself to use the DynaBean route and if you've read my posts here, you know I'm frustrated. I've been coming to your conclusion, and I'd love to hear more from you offline if you don't mind. I disagree vehemently that the idea of Maps in the Domain Model is a bad design. I worked for years in an architecture that eschewed many OO concepts as creating more work than they saved. Its universe was something like this- A Database contains a map of Table Objects A Table object contains an array list of Record Objects. A Record object contains a map of Field Objects. Etc Done properly, something like this could be infinitely reusable no matter what the application. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
NetSQL wrote: Even silly JSF uses RowSet as DTO. (RowSet is realy a ArrayList of HashMaps. Rows of Columns) What does a ArrayList of HashMaps get you over a java.sql.ResultSet? I'll tell you a big disadvantage: it keeps everything in memory. What if the result set is large? I look at it like this: -SQL is a Set oriented lang.(row by row processing is exponentialy slower) This is totally wrong: - SQL is a multi-set-oriented language, much to the disgust of many relational database users. - Exponentially doesn't mean a lot. It describes a function that asymptotically approaches e^n. - Putting all the data into another container _is_ row-by-row processing. You're always doing row-by-row processing, even just to fetch it from the database server. And once you've put it in whatever form you want, you still have to do row-by-row processing, or you've wasted your time fetching a lot of useless rows. Regards, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
On Thu, 10 Mar 2005 12:56:04 -0600, Scott Lamb [EMAIL PROTECTED] wrote: NetSQL wrote: Even silly JSF uses RowSet as DTO. (RowSet is realy a ArrayList of HashMaps. Rows of Columns) What does a ArrayList of HashMaps get you over a java.sql.ResultSet? The major disadvantage of using the RS directly is that it keeps the connection (and associated resources - statements, etc) open the entire time you have it. In a high load / limited resources application, this is a big deal, and why tools like iBATIS and Hibernate take this approach. RAM and CPU are way cheaper than more Oracle licenses. ;-) I'll tell you a big disadvantage: it keeps everything in memory. What if the result set is large? That is why we do the row handlers in ibatis - you get one row at a time with very little added weight over the result set. We also support a paginated list that only keeps a limited number of rows in memory. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
I've actually handled this in a previous project by writing a class that implements the ResultSet interface (well, *some* of it anyway). Internally the data gets stored as an ArrayList of HashMaps, so it's completely disconnected, and it's a drop-in replacement any place we would have used a ResultSet. As someone else said, memory utilization is the down-side to this approach, but if you have suitable hardware and know your resultset size won't kill you, this a great approach. We have actually found though that using it doesn't kill us memory-wise, and we do sometimes have some resultsets come back that I would consider large... but more importantly the application is considerably more efficient and responsive than using regular ResultSets precisely because connections and statements and such aren't being held open, so no waiting for a connection from the pool as much, etc. Hopefully we're going to start using a REAL persistance package around here soon (I'm doing some evaluation now), but until that day, we've found this to be an excellent solution in many situations. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, March 10, 2005 2:03 pm, Larry Meadors said: On Thu, 10 Mar 2005 12:56:04 -0600, Scott Lamb [EMAIL PROTECTED] wrote: NetSQL wrote: Even silly JSF uses RowSet as DTO. (RowSet is realy a ArrayList of HashMaps. Rows of Columns) What does a ArrayList of HashMaps get you over a java.sql.ResultSet? The major disadvantage of using the RS directly is that it keeps the connection (and associated resources - statements, etc) open the entire time you have it. In a high load / limited resources application, this is a big deal, and why tools like iBATIS and Hibernate take this approach. RAM and CPU are way cheaper than more Oracle licenses. ;-) I'll tell you a big disadvantage: it keeps everything in memory. What if the result set is large? That is why we do the row handlers in ibatis - you get one row at a time with very little added weight over the result set. We also support a paginated list that only keeps a limited number of rows in memory. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
On 10 Mar 2005, at 11:55, Scott Lamb wrote:
- consistent dynamic sql (from what I see, there are different ways
for altering the order and the where clauses..are there others?)
There's also the s:bindlist/, which is similar to your iterator.
Ahh, lost a later draft with more here.
There's no general-purpose lexical bind (like Oracle Forms Reports'
foo). I also don't have a way of quoting SQL identifiers, as I haven't
found the need. I sometimes execute queries like this:
declare
cursor grants is
selectgrantee, granted_role
from dba_role_privs
where granted_role in ('FOO', 'BAR');
begin
for grant in grants loop
execute immediate 'revoke ' ||
quote_identifier(grant.granted_role)
|| ' from ' || quote_identifier(grantee);
end loop;
end;
/
show errors
but those are infrequent admin tasks, and I'm happy just typing that
block into SQL*Plus. I don't know why you'd do that from a web app.
This is another case where I try to avoid implementing the feature
before I see what needs it. I waited on lexical binds and added instead
bind lists, conditionals, and dynamic order by clauses when each
presented its need. They've all been much better for the task than
lexical binds would be, and there might be some more left of that
nature.
--
Scott Lamb http://www.slamb.org/
PGP.sig
Description: This is a digitally signed message part
Re: Struts DB Access :: Best Practices
Scott Lamb wrote: NetSQL wrote: (RowSet is realy a ArrayList of HashMaps. Rows of Columns) What does a ArrayList of HashMaps get you over a java.sql.ResultSet? Collections are lighter and easier to SoA. I look at it like this: -SQL is a Set oriented lang.(row by row processing is exponentialy slower) This is totally wrong Maybe you think that. I think I am right. - Putting all the data into another container _is_ row-by-row processing. You're always doing row-by-row processing, even just to fetch it from the database server. Maybe you think that. JDBC drivers do not stream rows; it sends it after Select processing, joins, ordering, etc has been done. So if you do order by, and your table has millions of rows, 1st the SQL engine sorts and then it starts sending the millions of rows. DBCacnel... just stops the stream. Ex#2: you can create a cursor to give everyone in NYC a raise, and go by row by row. Or you can do a set operation in one command. I allways avoid row by row, and allways try to go for set, as per direction by Celko and others. Your millage may vary. When I need to display chunks of data I do limit/offset SQL side, not Java side. In Java, I let iBatis cache it for me w/o any code on my part. hth, .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
On 10 Mar 2005, at 13:48, NetSQL wrote: Ex#2: you can create a cursor to give everyone in NYC a raise, and go by row by row. Or you can do a set operation in one command. I allways avoid row by row, and allways try to go for set, as per direction by Celko and others. Your millage may vary. Okay, now I see what you are saying. Yes, a bulk UPDATE is certainly faster (and easier) than fetching a ResultSet and firing UPDATEs on each row. That's just a matter of using SQL properly. But this isn't the situation I was talking about. There are times it is legitimately necessary to get a large ResultSet in one gulp and pass it on to the client. This is what I was talking about; I don't want to keep the whole thing in memory. -- Scott Lamb http://www.slamb.org/ PGP.sig Description: This is a digitally signed message part
RE: Struts DB Access :: Best Practices
Hi all, Here's is a comment from a first time OJB user. I had to do a web project with a quiet large entity relationship model. Many 1toN and MtoN relations. So what do you do?! - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. I love this approach so much, because you just maintain one set of classes and manage everything through the xdoclet attributes. When I think of the system now I stay fully in my model. No more and then I have to insert that FK there... In fact if we had more stable computer I would write the PersistenceBrokerEmpty implementation ;-) Maybe it isn't the most efficient way to materialize an object with its relations or just a complete row if you only need a single entry. But why not next time it's gonna be in cache, who the hell cares in times of cheap memory. This is next millennium?! If you think in an OO way and if need a relational DB in the back you don't get around O/R mapping. GreetZ Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
Hi all, Here's is a comment from a first time OJB user. I had to do a web project with a quiet large entity relationship model. Many 1toN and MtoN relations. So what do you do?! - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. I love this approach so much, because you just maintain one set of classes and manage everything through the xdoclet attributes. When I think of the system now I stay fully in my model. No more and then I have to insert that FK there... In fact if we had more stable computer I would write the PersistenceBrokerEmpty implementation ;-) Maybe it isn't the most efficient way to materialize an object with its relations or just a complete row if you only need a single entry. But why not next time it's gonna be in cache, who the hell cares in times of cheap memory. This is next millennium?! If you think in an OO way and if need a relational DB in the back you don't get around O/R mapping. GreetZ Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Nils Liebelt wrote the following on 3/10/2005 3:10 PM: - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. Did you get to create the tables after you made up Model? That's a big difference than a huge majority of cases where you don't have that luxury of starting from scratch on the DB design. And that big difference makes a difference in how easy it is to use you a strict object only approach. You can brag about no SQL, but show me that same bragging of 'ease' where you have to work on a project where you can't start from scratch on the DB model. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
That's right. It's quiet a luxury not to deal with legacy shit... But even if. As long as the guy/gal who made up the DB is not fully incompetent. GreetZ Nils -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:20 PM To: Struts Users Mailing List Subject: Re: Struts DB Access :: Best Practices Nils Liebelt wrote the following on 3/10/2005 3:10 PM: - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. Did you get to create the tables after you made up Model? That's a big difference than a huge majority of cases where you don't have that luxury of starting from scratch on the DB design. And that big difference makes a difference in how easy it is to use you a strict object only approach. You can brag about no SQL, but show me that same bragging of 'ease' where you have to work on a project where you can't start from scratch on the DB model. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
That's right. It's quiet a luxury not to deal with legacy shit... But even if. As long as the guy/gal who made up the DB is not fully incompetent. GreetZ Nils -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:20 PM To: Struts Users Mailing List Subject: Re: Struts DB Access :: Best Practices Nils Liebelt wrote the following on 3/10/2005 3:10 PM: - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. Did you get to create the tables after you made up Model? That's a big difference than a huge majority of cases where you don't have that luxury of starting from scratch on the DB design. And that big difference makes a difference in how easy it is to use you a strict object only approach. You can brag about no SQL, but show me that same bragging of 'ease' where you have to work on a project where you can't start from scratch on the DB model. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
sarcasmSo, what is your favorite ide?/sarcasm I love these debates. Some of you guys have some really wacky ideas and to be honest it's entertaining. It's a crazy world out their and i'm glad i have all you nutcases to share it with. To be honest there are three persistence solutions that I would currently use out their (in general order of importance) 1) IBatis - cuz databases live longer than applications 2) JDBC- cuz databases live longer than applications 3) Hibernate -- cuz some databases are intrinsicly tied to the lifespan of the app and i have this perverse side that like unnecessary complexity. Thanks for making life interesting, Brandon On Thu, 10 Mar 2005 15:19:31 -0500, Rick Reumann [EMAIL PROTECTED] wrote: Nils Liebelt wrote the following on 3/10/2005 3:10 PM: - You make up your model. I use UML. - Look for a case tool where you can generate some code. Poseidon is great. - Put in the your xdoclet tags for the mapping. - Put in your xdoclet tags for the form beans. - May be write a couple conversion classes from form beans to businessobjects and from businessobjects to DB. - Write an Interface for Querying your objects the way you need them. That's it. Straight forward! 28 tables and not a single line of SQL. But it is not about SQL. Did you get to create the tables after you made up Model? That's a big difference than a huge majority of cases where you don't have that luxury of starting from scratch on the DB design. And that big difference makes a difference in how easy it is to use you a strict object only approach. You can brag about no SQL, but show me that same bragging of 'ease' where you have to work on a project where you can't start from scratch on the DB model. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Struts using Hibernate. Hibernate is quite easy to learn and has a large community. Regards Sebastian Hennebrueder http://www.laliluna.de Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB karthikeyan balasubramanian wrote: Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
karthikeyan balasubramanian wrote: I want to know what is the best way to access database using struts. This is just one way: http://www.ibatis.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts DB Access :: Best Practices
i prefer to use OJB for persistence, because i like the approach of coming from the object world and define the mapping to the database, while hibernate (and others) tend to come from the database and help you generate classes. OJB is very easy to use, and you won't see anything related like PK-FK or id within your java code which makes it easy to read and has nothing database related in it. but if you have the need to tune performance etc. OJB gives you access to everything, inluding using stored procedures. kr, guenther -- Günther Wieser creative-it Guglgasse 6/1/11/1 A-1110 Wien Austria http://www.creative-it.com -Original Message- From: karthikeyan balasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:19 AM To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
I do not completely agree here. You can choose from where you come and to where you go using Hibernate. As other approach I only know EJB and here it depends on the tools you have. With xDoclet your start with the class and go to the db over the mappings. Regards Sebastian Hennebrueder http://www.laliluna.de Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB Günther Wieser wrote: i prefer to use OJB for persistence, because i like the approach of coming from the object world and define the mapping to the database, while hibernate (and others) tend to come from the database and help you generate classes. OJB is very easy to use, and you won't see anything related like PK-FK or id within your java code which makes it easy to read and has nothing database related in it. but if you have the need to tune performance etc. OJB gives you access to everything, inluding using stored procedures. kr, guenther -- Günther Wieser creative-it Guglgasse 6/1/11/1 A-1110 Wien Austria http://www.creative-it.com -Original Message- From: karthikeyan balasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:19 AM To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Hi all, Thank you all for inputs. Now my list has grown big : 1. Castor 2. JDO 3. iBATIS 4. Hibernate 5. OJB I looked at iBATIS, it seems to be simple and easy to use. I will also check out others and let you know my thoughts. Have a great day. Karthikeyan B On Wed, 09 Mar 2005 11:31:50 +0100, Sebastian Hennebrueder [EMAIL PROTECTED] wrote: I do not completely agree here. You can choose from where you come and to where you go using Hibernate. As other approach I only know EJB and here it depends on the tools you have. With xDoclet your start with the class and go to the db over the mappings. Regards Sebastian Hennebrueder http://www.laliluna.de Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB Günther Wieser wrote: i prefer to use OJB for persistence, because i like the approach of coming from the object world and define the mapping to the database, while hibernate (and others) tend to come from the database and help you generate classes. OJB is very easy to use, and you won't see anything related like PK-FK or id within your java code which makes it easy to read and has nothing database related in it. but if you have the need to tune performance etc. OJB gives you access to everything, inluding using stored procedures. kr, guenther -- Günther Wieser creative-it Guglgasse 6/1/11/1 A-1110 Wien Austria http://www.creative-it.com -Original Message- From: karthikeyan balasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:19 AM To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
shameless plug Equinox (http://equinox.dev.java.net) allows you to use Struts+Spring and any of the following persistence engines: Hibernate iBATIS JDO (JPOX) OJB Spring JDBC /shameless plug Personally, I like Hibernate when I get to create my schema, and iBATIS when it already exists. iBATIS is the easiest to learn/use in my experience. Matt On Mar 9, 2005, at 4:40 AM, karthikeyan balasubramanian wrote: Hi all, Thank you all for inputs. Now my list has grown big : 1. Castor 2. JDO 3. iBATIS 4. Hibernate 5. OJB I looked at iBATIS, it seems to be simple and easy to use. I will also check out others and let you know my thoughts. Have a great day. Karthikeyan B On Wed, 09 Mar 2005 11:31:50 +0100, Sebastian Hennebrueder [EMAIL PROTECTED] wrote: I do not completely agree here. You can choose from where you come and to where you go using Hibernate. As other approach I only know EJB and here it depends on the tools you have. With xDoclet your start with the class and go to the db over the mappings. Regards Sebastian Hennebrueder http://www.laliluna.de Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB Günther Wieser wrote: i prefer to use OJB for persistence, because i like the approach of coming from the object world and define the mapping to the database, while hibernate (and others) tend to come from the database and help you generate classes. OJB is very easy to use, and you won't see anything related like PK-FK or id within your java code which makes it easy to read and has nothing database related in it. but if you have the need to tune performance etc. OJB gives you access to everything, inluding using stored procedures. kr, guenther -- Günther Wieser creative-it Guglgasse 6/1/11/1 A-1110 Wien Austria http://www.creative-it.com -Original Message- From: karthikeyan balasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:19 AM To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
I agree that you can use Hibernate to generate code in a top-down or bottom-up approach fairly easily. However, I would disagree with your earlier comment that Hibernate is very easy to learn. It is a powerful tool and makes life easier once you learn it, but I think realistically you are looking at a 3 to 6 week learning curve to really figure out how everything fits together and develop a working architecture. I highly recommend getting a copy of Hibernate in Action to help get everything sorted out. The tutorials at http://www.laliluna.de are also a good resource. ( Thanks for those btw! ) regards, -j quote I do not completely agree here. You can choose from where you come and to where you go using Hibernate. As other approach I only know EJB and here it depends on the tools you have. With xDoclet your start with the class and go to the db over the mappings. Regards Sebastian Hennebrueder http://www.laliluna.de Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB Günther Wieser wrote: i prefer to use OJB for persistence, because i like the approach of coming from the object world and define the mapping to the database, while hibernate (and others) tend to come from the database and help you generate classes. OJB is very easy to use, and you won't see anything related like PK-FK or id within your java code which makes it easy to read and has nothing database related in it. but if you have the need to tune performance etc. OJB gives you access to everything, inluding using stored procedures. kr, guenther -- Günther Wieser creative-it Guglgasse 6/1/11/1 A-1110 Wien Austria http://www.creative-it.com -Original Message- From: karthikeyan balasubramanian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:19 AM To: user@struts.apache.org Subject: Struts DB Access :: Best Practices Hi all, I am planning to use Tomcat/Struts/MySQL in my project. Database operation's can involve more selects and little bit of update/insert operations. I want to know what is the best way to access database using struts. I did a research and found few good ways: 1. Struts using Castor. 2. Struts using JDO. I found Struts with Castor easy to use. What you guys/gals think on What is the best practices to access DB from Struts?. Any inputs here would enable me to make good decision :) Looking forward for yours response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /quote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
karthikeyan balasubramanian wrote: I looked at iBATIS, it seems to be simple and easy to use. I will also check out others and let you know my thoughts. I'll add one to your list: Axamol SQL Library http://www.slamb.org/projects/axamol/sql-library/ It's a project of mine, so I'd love to hear if it works out for you. (Or if it doesn't do what you need, but could if I added feature X.) It is similar to iBATIS SQL Maps but lighter / narrower in scope. I looked over their user manual recently, and the differences I spotted were: - iBATIS does database pooling for you; Axamol does not. I prefer to use the servlet container's built-in pooling. - iBATIS does caching; Axamol does not. I haven't encountered the situation in which I'd want quite the caching they have. - iBATIS has a lot of options to use JavaBeans, which I don't find useful. I just take parameters in a java.util.Map and return a java.sql.ResultSet directly. (I'm a DynaActionForm kind of guy, so using a form bean form this would be a little out of place.) - iBATIS has a lot of support for translating magic values (of the 9/9/99 variety) into nulls, which is a fundamentally bad idea. Axamol doesn't do this and never will. - iBATIS's conditional SQL elements have this prepend=... attribute that I find confusing. I accomplish the same thing just by using boolean identities: true and boolvar = false or boolvar = boolvar. Compare the example on iBATIS SQL Map's developer guide page 35 to my example two at http://www.slamb.org/projects/axamol/sql-library/manual/pr01s02.html and you'll see what I'm getting at. - Axamol includes XSLT and standardized elements for embedding documentation in your libraries and producing HTML for them. - Axamol captures timing statistics which are useful for determining where you need to optimize your SQL. Good luck, whatever you end up using. Regards, Scott -- Scott Lamb http://www.slamb.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DB Access :: Best Practices
Jesse Clark wrote the following on 3/9/2005 4:46 PM: However, I would disagree with your earlier comment that Hibernate is very easy to learn. It is a powerful tool and makes life easier once you learn it, but I think realistically you are looking at a 3 to 6 week learning curve to really figure out how everything fits together and develop a working architecture. I'd even disagree that it makes things easier once you learn it. I'd say only sometimes. It often creates a lot of headaches and you'll definitely run into difficulties if you don't own the tables and you can't create the table structure the way you want it. On the other hand, plugging iBATIS again, iBATIS doesn't care what the table structure is like. One of the great things about iBATIS is that as a developer I can get a nice optimized piece of pure SQL from a DBA using existing tables and can use that exact query/update in iBATIS (no need to even learn another query language either). I think it's great having competing frameworks. Only makes all of them better. Personally I find iBATIS simple and powerful. I also have to say that I think all the apparent buzz around Hibernate is based purely on politics (Same thing with Spring.) Not saying both aren't solid products, but they are often pushed in the same breath at conferences etc without even considering alternatives that might be better and/or easier to use. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
