Re: New version of Tapernate...
On 5/24/06, James Carman [EMAIL PROTECTED] wrote: No problem! Just to be clear about why your situation is working now, I removed the transaction interceptor from the persistence strategies and the squeezer. With transaction-per-request turned on, these features work just fine. You can disable transaction-per-request, but I would imagine that the majority of Tapernate users are using it. Again, Tapernate is a work in progress, so I'm trying to figure out the best way to get around this issue. I really don't like the fact that the Spring transaction interceptor throws an exception. I think I can let it just go by without rolling back the transaction and without throwing an exception. I'll try to figure that out. Well James i think you mistaken person, but my thanks goes anyway! :) -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New version of Tapernate...
Oops! I'm sorry, Massimo. I was up late last night coding that stuff, so I must have been a bit tired. I meant to reply to Marcus Matèrn. He was having an issue with rollbacks in Tapernate. -Original Message- From: Massimo Lusetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 9:36 AM To: Tapestry users Subject: Re: New version of Tapernate... On 5/24/06, James Carman [EMAIL PROTECTED] wrote: No problem! Just to be clear about why your situation is working now, I removed the transaction interceptor from the persistence strategies and the squeezer. With transaction-per-request turned on, these features work just fine. You can disable transaction-per-request, but I would imagine that the majority of Tapernate users are using it. Again, Tapernate is a work in progress, so I'm trying to figure out the best way to get around this issue. I really don't like the fact that the Spring transaction interceptor throws an exception. I think I can let it just go by without rolling back the transaction and without throwing an exception. I'll try to figure that out. Well James i think you mistaken person, but my thanks goes anyway! :) -- Massimo http://meridio.blogspot.com - 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: New version of Tapernate...
It's available via svn from my server http://www.carmanconsulting.com/svn/public/tapernate/trunk Or, you can download the example application which has all the jars you'll need already set up for you to use. http://www.carmanconsulting.com/svn/public/tapernate-example/trunk -Original Message- From: Henri Dupre [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:18 PM To: Tapestry users Subject: Re: New version of Tapernate... Hi James, On 5/24/06, James Carman [EMAIL PROTECTED] wrote: 2. Taperate now has support for three types of property persistence, reattach-merge (used to be called entity), reattach-lock, and reattach-update, corresponding to the three different types of reattach strategies. You can choose which one you want to use for your situation (reattach-update doesn't support POJO rollback, though since Hibernate will not give me the previous values for some reason) giving you more fine-grained control. 3. The spring.hibernate3 module now supports an interceptor pipeline. So, you can add as many interceptor filters as you wish, which can do various actions (logging, auditing, etc.). The POJO rollback is implemented as an interceptor filter. Tapernate will move soon. I finally got the Maven2 build to work, so now I just have to upload it and set up some docs for it. For those of you who are currently using Tapernate, you don't have to upgrade, but it's strongly suggested. Again, where is tapernate located? I searched last time on Howard's site where he has tapestry-spring and other small projects but I couldn't find your project. I'd be interested to know more about your different reattach strategies... Do you understand in details which one to use when? To me lock should always be used unless you have duplicate objects, right? And having duplicate objects is not good in hibernate, if I get it right? I like the idea of an interceptor pipeline... Would it allow easily to monitor performance of DAO methods? Thanks, Henri. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New version of Tapernate...
One question,
If I retrieve an object from my DAO and change something in that
object without doing a session.update(...), the change will be
persisted (to the DB). Is this the way it should work (not having to
do a manual update) ?
public Product getProduct()
{
Product product;
product = getProductAccess().getProduct(getId());
product.setContent(this text will be written to DB);
return product;
}
Marcus
On 5/24/06, Marcus Matèrn [EMAIL PROTECTED] wrote:
Henri,
http://www.carmanconsulting.com/svn/public/
James, I'm also very greatful. Thanks!
On 5/24/06, Henri Dupre [EMAIL PROTECTED] wrote:
Hi James,
On 5/24/06, James Carman [EMAIL PROTECTED] wrote:
2. Taperate now has support for three types of property persistence,
reattach-merge (used to be called entity), reattach-lock, and
reattach-update, corresponding to the three different types of reattach
strategies. You can choose which one you want to use for your situation
(reattach-update doesn't support POJO rollback, though since Hibernate
will
not give me the previous values for some reason) giving you more
fine-grained control.
3. The spring.hibernate3 module now supports an interceptor pipeline.
So, you can add as many interceptor filters as you wish, which can do
various actions (logging, auditing, etc.). The POJO rollback is
implemented
as an interceptor filter.
Tapernate will move soon. I finally got the Maven2 build to work, so now
I
just have to upload it and set up some docs for it. For those of you who
are currently using Tapernate, you don't have to upgrade, but it's
strongly
suggested.
Again, where is tapernate located? I searched last time on Howard's site
where he has tapestry-spring and other small projects but I couldn't find
your project.
I'd be interested to know more about your different reattach strategies...
Do you understand in details which one to use when?
To me lock should always be used unless you have duplicate objects, right?
And having duplicate objects is not good in hibernate, if I get it right?
I like the idea of an interceptor pipeline... Would it allow easily to
monitor performance of DAO methods?
Thanks,
Henri.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: New version of Tapernate...
Yes, that's correct. Using an ORM requires a different mindset. In fact,
there was a pretty interesting post on TheServerSide.com yesterday about
this very topic:
http://www.theserverside.com/news/thread.tss?thread_id=40581
-Original Message-
From: Marcus Matèrn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 1:28 PM
To: Tapestry users
Subject: Re: New version of Tapernate...
One question,
If I retrieve an object from my DAO and change something in that
object without doing a session.update(...), the change will be
persisted (to the DB). Is this the way it should work (not having to
do a manual update) ?
public Product getProduct()
{
Product product;
product = getProductAccess().getProduct(getId());
product.setContent(this text will be written to DB);
return product;
}
Marcus
On 5/24/06, Marcus Matèrn [EMAIL PROTECTED] wrote:
Henri,
http://www.carmanconsulting.com/svn/public/
James, I'm also very greatful. Thanks!
On 5/24/06, Henri Dupre [EMAIL PROTECTED] wrote:
Hi James,
On 5/24/06, James Carman [EMAIL PROTECTED] wrote:
2. Taperate now has support for three types of property persistence,
reattach-merge (used to be called entity), reattach-lock, and
reattach-update, corresponding to the three different types of
reattach
strategies. You can choose which one you want to use for your
situation
(reattach-update doesn't support POJO rollback, though since Hibernate
will
not give me the previous values for some reason) giving you more
fine-grained control.
3. The spring.hibernate3 module now supports an interceptor
pipeline.
So, you can add as many interceptor filters as you wish, which can
do
various actions (logging, auditing, etc.). The POJO rollback is
implemented
as an interceptor filter.
Tapernate will move soon. I finally got the Maven2 build to work, so
now
I
just have to upload it and set up some docs for it. For those of you
who
are currently using Tapernate, you don't have to upgrade, but it's
strongly
suggested.
Again, where is tapernate located? I searched last time on Howard's site
where he has tapestry-spring and other small projects but I couldn't
find
your project.
I'd be interested to know more about your different reattach
strategies...
Do you understand in details which one to use when?
To me lock should always be used unless you have duplicate objects,
right?
And having duplicate objects is not good in hibernate, if I get it
right?
I like the idea of an interceptor pipeline... Would it allow easily to
monitor performance of DAO methods?
Thanks,
Henri.
-
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: New version of Tapernate...
This brings up some questions..
If I work directly on my domain model in the tapestry layer, then
data on forms that do _not_ validate, get persisted. This on the other
hand could be solved by calling setRollBackOnly() if the form didn't
validate.
But if the edited object get passed around on different pages (e.g.
some kind of preview service or multiple step form wizard etc..) the
object gets saved outside of my control.
I want my altered objects to go through my business layer before they
get persisted.
Any suggestions here? I need to settle for a design that gives me
total control of what is persisted and what is not.
Maybe I shouldn't have domain objects in my tapestry layer...?
2006/5/24, James Carman [EMAIL PROTECTED]:
Yes, that's correct. Using an ORM requires a different mindset. In fact,
there was a pretty interesting post on TheServerSide.com yesterday about
this very topic:
http://www.theserverside.com/news/thread.tss?thread_id=40581
-Original Message-
From: Marcus Matèrn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 1:28 PM
To: Tapestry users
Subject: Re: New version of Tapernate...
One question,
If I retrieve an object from my DAO and change something in that
object without doing a session.update(...), the change will be
persisted (to the DB). Is this the way it should work (not having to
do a manual update) ?
public Product getProduct()
{
Product product;
product = getProductAccess().getProduct(getId());
product.setContent(this text will be written to DB);
return product;
}
Marcus
On 5/24/06, Marcus Matèrn [EMAIL PROTECTED] wrote:
Henri,
http://www.carmanconsulting.com/svn/public/
James, I'm also very greatful. Thanks!
On 5/24/06, Henri Dupre [EMAIL PROTECTED] wrote:
Hi James,
On 5/24/06, James Carman [EMAIL PROTECTED] wrote:
2. Taperate now has support for three types of property persistence,
reattach-merge (used to be called entity), reattach-lock, and
reattach-update, corresponding to the three different types of
reattach
strategies. You can choose which one you want to use for your
situation
(reattach-update doesn't support POJO rollback, though since Hibernate
will
not give me the previous values for some reason) giving you more
fine-grained control.
3. The spring.hibernate3 module now supports an interceptor
pipeline.
So, you can add as many interceptor filters as you wish, which can
do
various actions (logging, auditing, etc.). The POJO rollback is
implemented
as an interceptor filter.
Tapernate will move soon. I finally got the Maven2 build to work, so
now
I
just have to upload it and set up some docs for it. For those of you
who
are currently using Tapernate, you don't have to upgrade, but it's
strongly
suggested.
Again, where is tapernate located? I searched last time on Howard's site
where he has tapestry-spring and other small projects but I couldn't
find
your project.
I'd be interested to know more about your different reattach
strategies...
Do you understand in details which one to use when?
To me lock should always be used unless you have duplicate objects,
right?
And having duplicate objects is not good in hibernate, if I get it
right?
I like the idea of an interceptor pipeline... Would it allow easily to
monitor performance of DAO methods?
Thanks,
Henri.
-
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]
--
/ted
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
