You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@zenplex.com> on 2001/10/31 16:44:16 UTC
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
On 10/31/01 10:19 AM, "Fedor Karpelevitch" <fe...@Barra.COM>
wrote:
> I understand Jason's point. However I believe we still need
> save(DBConnection) (or replacement) type of methods.
Sure, it's required now because we haven't implemented a replacement or
redesigned it but the interface an OM object adheres to should be as simple
as possible. Do we really need more than save()/update()/delete()?
> The reason is that
> these allow to do multiple operations in one transaction. And transaction
> does not necessarily means db transaction - it may be JTA transaction or
> something else.
Sure, again I think that Ambler's work covers this well. As your persistence
store may be something other than a database. You definitely want some
safety in writing to an XML store that may be located on a network somewhere
or whatever.
> So solution I see is to have an interface (call it
> Transaction for example) which DBConnection (and possibly others would
> implement. I hope save(Transaction) sounds better to you? Of course an
> object would only be able to use a specific implementation of Transaction by
> downcasting it.
If it's at all possible I would like just save() and have the info about the
object's store location and the type of transaction required to save it
somewhere else. I would like to bend torque closer to Ambler's design but I
think he does have save(Transaction) in there somewhere if I remember
correctly.
> As far as Byron's suggestion goes, problem with it is that in some cases
> this may be what you want, but not always. For example you may want to use
> several connections in the same thread at the same time. So this does not
> work as a general solution, but can be an option if there is a reasonable
> way to make it that way...
>
> fedor.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
>> I like save(Transaction), but it is really much like save(DBConnection).
>
> Not if we are storing objects somewhere other than a database :-)
Great point.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/31/01 1:20 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> If it's at all possible I would like just save() and have the info about the
>> object's store location and the type of transaction required to save it
>> somewhere else. I would like to bend torque closer to Ambler's design but I
>> think he does have save(Transaction) in there somewhere if I remember
>> correctly.
>
> I like save(Transaction), but it is really much like save(DBConnection).
Not if we are storing objects somewhere other than a database :-)
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> If it's at all possible I would like just save() and have the info about the
> object's store location and the type of transaction required to save it
> somewhere else. I would like to bend torque closer to Ambler's design but I
> think he does have save(Transaction) in there somewhere if I remember
> correctly.
I like save(Transaction), but it is really much like save(DBConnection).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque
NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/31/01 12:59 PM, "Ilia Iourovitski" <ii...@ydyn.com> wrote:
> Well, in the Ambler's design at least three classes has
> (save/retrive/delete) methods :
> PersistenceBroker, PersistenceObject, PersistenceTransaction.
> Will Torque have all of them?
remains to be seen, someone donated some code that is based on ambler's
design and I've worked on them a bit but haven't touched them for a while. I
would rather try to merge more of ambler's design into torque. I honestly
don't feel like rewriting anything because torque is very functional even
though I think it needs a lot of work. Code and docs.
> Thanks
>
> Ilia
>
>
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Wednesday, October 31, 2001 7:44 AM
> To: Turbine Developers List
> Subject: Re: transaction management (RE: cvs
> commit:jakarta-turbine-torque NO TES)
>
>
> On 10/31/01 10:19 AM, "Fedor Karpelevitch" <fe...@Barra.COM>
> wrote:
>
>> I understand Jason's point. However I believe we still need
>> save(DBConnection) (or replacement) type of methods.
>
> Sure, it's required now because we haven't implemented a replacement or
> redesigned it but the interface an OM object adheres to should be as simple
> as possible. Do we really need more than save()/update()/delete()?
>
>> The reason is that
>> these allow to do multiple operations in one transaction. And transaction
>> does not necessarily means db transaction - it may be JTA transaction or
>> something else.
>
> Sure, again I think that Ambler's work covers this well. As your persistence
> store may be something other than a database. You definitely want some
> safety in writing to an XML store that may be located on a network somewhere
> or whatever.
>
>> So solution I see is to have an interface (call it
>> Transaction for example) which DBConnection (and possibly others would
>> implement. I hope save(Transaction) sounds better to you? Of course an
>> object would only be able to use a specific implementation of Transaction
> by
>> downcasting it.
>
> If it's at all possible I would like just save() and have the info about the
> object's store location and the type of transaction required to save it
> somewhere else. I would like to bend torque closer to Ambler's design but I
> think he does have save(Transaction) in there somewhere if I remember
> correctly.
>
>> As far as Byron's suggestion goes, problem with it is that in some cases
>> this may be what you want, but not always. For example you may want to use
>> several connections in the same thread at the same time. So this does not
>> work as a general solution, but can be an option if there is a reasonable
>> way to make it that way...
>>
>> fedor.
>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: transaction management (RE: cvs commit:jakarta-turbine-torque NO TES)
Posted by Ilia Iourovitski <ii...@ydyn.com>.
Well, in the Ambler's design at least three classes has
(save/retrive/delete) methods :
PersistenceBroker, PersistenceObject, PersistenceTransaction.
Will Torque have all of them?
Thanks
Ilia
-----Original Message-----
From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
Sent: Wednesday, October 31, 2001 7:44 AM
To: Turbine Developers List
Subject: Re: transaction management (RE: cvs
commit:jakarta-turbine-torque NO TES)
On 10/31/01 10:19 AM, "Fedor Karpelevitch" <fe...@Barra.COM>
wrote:
> I understand Jason's point. However I believe we still need
> save(DBConnection) (or replacement) type of methods.
Sure, it's required now because we haven't implemented a replacement or
redesigned it but the interface an OM object adheres to should be as simple
as possible. Do we really need more than save()/update()/delete()?
> The reason is that
> these allow to do multiple operations in one transaction. And transaction
> does not necessarily means db transaction - it may be JTA transaction or
> something else.
Sure, again I think that Ambler's work covers this well. As your persistence
store may be something other than a database. You definitely want some
safety in writing to an XML store that may be located on a network somewhere
or whatever.
> So solution I see is to have an interface (call it
> Transaction for example) which DBConnection (and possibly others would
> implement. I hope save(Transaction) sounds better to you? Of course an
> object would only be able to use a specific implementation of Transaction
by
> downcasting it.
If it's at all possible I would like just save() and have the info about the
object's store location and the type of transaction required to save it
somewhere else. I would like to bend torque closer to Ambler's design but I
think he does have save(Transaction) in there somewhere if I remember
correctly.
> As far as Byron's suggestion goes, problem with it is that in some cases
> this may be what you want, but not always. For example you may want to use
> several connections in the same thread at the same time. So this does not
> work as a general solution, but can be an option if there is a reasonable
> way to make it that way...
>
> fedor.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque NO TES)
Posted by Fedor Karpelevitch <fe...@home.com>.
i guess there should be setDeleted() and save()
On 31 October 2001 11:56, you wrote:
> delete() could entail deleting the information from the db, possibly
> preceded by copying the data into an archive, or it could mean save()
> preceded by setting a DELETED flag to true. Does delete() only cover
> the first part of the first way of deleting?
>
> john mcnally
>
> Jason van Zyl wrote:
> > On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
> > > On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> > >> On 10/31/01 10:19 AM, "Fedor Karpelevitch"
> > >> <fe...@Barra.COM>
> > >>
> > >> wrote:
> > >>> I understand Jason's point. However I believe we still need
> > >>> save(DBConnection) (or replacement) type of methods.
> > >>
> > >> Sure, it's required now because we haven't implemented a replacement
> > >> or redesigned it but the interface an OM object adheres to should be
> > >> as simple
> > >> as possible. Do we really need more than save()/update()/delete()?
> > >
> > > or even just save() and delete()
> >
> > yes!
> >
> > > -Eric
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org> For additional
> > > commands, e-mail: <ma...@jakarta.apache.org>
> >
> > --
> >
> > jvz.
> >
> > Jason van Zyl
> >
> > http://tambora.zenplex.org
> > http://jakarta.apache.org/turbine
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/alexandria
> > http://jakarta.apache.org/commons
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org> For additional
> > commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque NO
TES)
Posted by John McNally <jm...@collab.net>.
delete() could entail deleting the information from the db, possibly
preceded by copying the data into an archive, or it could mean save()
preceded by setting a DELETED flag to true. Does delete() only cover
the first part of the first way of deleting?
john mcnally
Jason van Zyl wrote:
>
> On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
>
> >
> > On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> >
> >> On 10/31/01 10:19 AM, "Fedor Karpelevitch"
> >> <fe...@Barra.COM>
> >> wrote:
> >>
> >>> I understand Jason's point. However I believe we still need
> >>> save(DBConnection) (or replacement) type of methods.
> >>
> >> Sure, it's required now because we haven't implemented a replacement or
> >> redesigned it but the interface an OM object adheres to should be as
> >> simple
> >> as possible. Do we really need more than save()/update()/delete()?
> >
> > or even just save() and delete()
>
> yes!
>
> > -Eric
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
>
> On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
>
>> On 10/31/01 10:19 AM, "Fedor Karpelevitch"
>> <fe...@Barra.COM>
>> wrote:
>>
>>> I understand Jason's point. However I believe we still need
>>> save(DBConnection) (or replacement) type of methods.
>>
>> Sure, it's required now because we haven't implemented a replacement or
>> redesigned it but the interface an OM object adheres to should be as
>> simple
>> as possible. Do we really need more than save()/update()/delete()?
>
> or even just save() and delete()
yes!
> -Eric
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Eric Dobbs <er...@dobbse.net>.
On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> On 10/31/01 10:19 AM, "Fedor Karpelevitch"
> <fe...@Barra.COM>
> wrote:
>
>> I understand Jason's point. However I believe we still need
>> save(DBConnection) (or replacement) type of methods.
>
> Sure, it's required now because we haven't implemented a replacement or
> redesigned it but the interface an OM object adheres to should be as
> simple
> as possible. Do we really need more than save()/update()/delete()?
or even just save() and delete()
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>