[Seaside] Re: Application/Session Objects

[Yanni Chiu]

Richard Huxton wrote:
>> 2. it's gotten from a pool for each transaction
> 
> That's what I'm trying to do.

That same code that Julian pointed at has a pool implementation
you could probably adapt. I didn't look at it very closely.

> Yep. If I'm running pgpool and memcached anyway then I'll go back to PHP 
> or Perl - I've got plenty of libraries to do form building/validation 
> there.

Not sure I get the point here. How are connection pooling
and object/row caching inter-related? Are you talking about
object caching (i.e. as in a typical Object-Relational mapping
framework)?

> Hmm - practical example: An update query might fail. I want to do two 
> things:
> 1. Log the error to the database application_log table. I'll do this as 
> step 1 because I don't know if step 2 will succeed.
> 2. Recover from/correct the error.
> 
> At this point I need *two* connections for this one req/response, and 
> connection #2 could span multiple req/response if I needed it to. I've 
> had to do something similar to this in PHP (and work around a bug in the 
> libraries while doing so).
> 
> Does this make sense, or am I approaching it the wrong way for an 
> object-oriented persistent framework?

Makes a lot of sense to me. That's the typical application
logic to be implemented, once you get beyond row updates.
I'm somewhat hesitant to suggest an Object-Relational
mapping framework (e.g. Glorp), because IMHO an O-R framework's
complexity and constraints can become a bigger problem than the
original application problem you were trying to solve.
For example, you usage of two connections might require
some shoehorning.