For R/W:
But of course one can do master/Detail, or many to many, or more complicated updates, in fact most updates are "compound". See if I can explain this, but it takes using the tool between the ears:
For multi table updates I create a nested bean. Master/Detail like.
I always start by creating base beans, simple beans that are unit tested, and have a dao, but have a singe table.
Then I created a C bean that extends bean A, and has a bean B. (is a/has a is very OO **)
Bean C has 2 tables now. (you get the idea?) It has a B getB() method. I override next (for iteration) to go next on the A and B, find {to do super.find() (for A) and B.find for b }, save { super.save(), B.save() }, etc.
With this Zero copy approach, I can get very high transactions rates for low overhead. Compare this to multi copy and ineficient aproach of array list of objects when you need to do updetable master detail processing.
Why is this Zero copy? Because the cached or disconnected row set, where the retrieval happens, is where the setters fire. (Advanced: My beans are actually collections with getRow so they can do multi row updates, but .... they look like regular beans).
I can change DAO implementation at will as well. I can use same bean in console, or Model 1, or Soap, etc. since DAO lets me create a DBCP pool or use the pool of the container (based on properties).
My Beans of type C are tied to the presentation layer.
OT: (Since my beans of type C are tied to the presentation, I do presentation first on my projects as a "contract" with 0 code until the presentation layers is accepted and signed of by a client.
The presentation just has actions that forward to "success", nothing else, maybe some other navigation logic.
The JSPs the client sees look real, as a finished app. It has tiles, and CSS, but no java code, no point in coding until the client signs of. Once the client says, yes, this is the what I want (Just blank actions and JSP) then I start coding the "simple beans" that I unit test. Then I create the bus. compound beans (is a/ has a) and unit test them. Thus I have benefits of layered iterative approach. The thing that I will be adding soon to "example app" , is more browser side procesing in XFORMS, and JavaScript.
Consider allways writing presentation and action mappings first in Model 2, then beans come natural. That is why you do MVC layers, right, so you can unit test each!).
.V
** Some people do not realize that Java is OO capable. Java does not produce OO reusable code on it's own, it compiles fine linear, but you could if you have experience make it reusable via OO. This lets me reuse beans, and other things.
John Bigboote wrote:
Hmm, I think that's implementation dependent. For example, the Oracle CachedRowSet implementation doesn't support updating joined tables. See:http://otn.oracle.com/docs/products/ias/doc_library/90200doc_otn/web.902/a90211/rowset.htm#628357 I don't know for sure, but I'll wager the RI doesn't, either... John --- Jerry Jalenak <[EMAIL PROTECTED]> wrote:My initial SQL SELECT statement that creates my
ResultSet pulls data from several tables. I wasn't
sure if the RowSetWriter implementation would be
able to accommodate this scenario, so I've started
using the CachedRowSet object as a means of passing data from DAO to business logic and back. I had to kill the writer in order to use the
'acceptChanges()'method. Does the default RowSetWriter handle updating multiple tables?
Jerry
-----Original Message----- From: John Bigboote [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 2:23 PM To: Struts Users Mailing List Subject: Re: [OT] Updating CachedRowSet --- Jerry Jalenak <[EMAIL PROTECTED]>wrote:[...snip...]crs.updateString("userInfo", userInfo); crs.updateRow(); crs.setWriter(null); // kill default writer crs.acceptChanges();Why are you setting the writer to null? It's the RowSetWriter that propagates changes back to the database... John __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign upnow.http://mailplus.yahoo.com
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>This transmission (and any information attached to
it) may be confidential and is intended solely for
the use of the individual or entity to which it is
addressed. If you are not the intended recipient or
the person responsible for delivering the
transmission to the intended recipient, be advised
that you have received this transmission in error
and that any use, dissemination, forwarding,
printing, or copying of this information is strictly
prohibited. If you have received this transmission
in error, please immediately notify LabOne at the
following email address:
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
