On Thu, Jun 29, 2000 at 07:46:33AM -0400, Nissim wrote:
> I'm replying to this message because there's an additional issue I
> didn't address with this patch. Although the patch in the previous
> message will work for postgres for the user stuff, it's not a general
> solution to using tables which contain large objects in postgres. So
> when you start making peer classes for the attachment tables in scarab
> (or any other tables containing binary data), you're going to have the
> same problem again.
Yes - and there's also potentially maintenance problems with deriving
special classes for postgres (although inheritance minimizes these).
I still favour the db.objectDataNeedsTrans() solution - once it's in
there it won't need thinking about whatever one does with Postgres. But
then I don't know what the overhead of a transaction where one is not
necessary is. If there isn't really much cost then something more like
John suggested is probably cleaner.
In any case I don't think anyone's actually said _no_ - the main thing
is to have had a rummage around for ideas to check that we choose well.
As an aside, a problem I see with any automatic mechanism to do this is
that as things stand it won't know if we're in a transaction anyway.
Perhaps as your patches use a DBConnection as the cookie (the right
choice IMO by the way) we could add an 'inTransaction' property to it?
--
Sean Legassick
[EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
