Good point. It still irks me to have two DA's though. It gets confusing
with the three different DA's running around now, much less if one of
actually had two valid versions. What if we had two classes like you
said, but
then in the manage_addForm had a checkbox for Transactions enabled,
which would
determine which Class got instantiated? Any good reasons why that
shouldn't work?


Andy Dustman wrote:
> On Tue, 1 Aug 2000, Monty Taylor wrote:
> > A question would be, what should the commit/rollback mechanism decide to
> > do when the transaction deals with tables of both types.
> It should raise ProgrammingError, "You're screwed".
> If you need transactional capabilities, then you just can't mix
> transactional and non-transactional tables in MySQL. This is also why I
> think there need to be two Zope DAs for MySQL: Non-transactional and
> transactional, the latter being a simple subclass of the former with TM
> support mixed-in. The choice of whether or not to be transactional should
> be made by the application designer; it's too complicated to make at
> run-time (i.e. for each query). Even if you can use the API to find the
> table type, you stil have to figure out what tables are used by the query,
> and that requires parsing SQL.
> --
> andy dustman       |     programmer/analyst     |, inc.
> telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
> "Therefore, sweet knights, if you may doubt your strength or courage,
> come no further, for death awaits you all, with nasty, big, pointy teeth!"

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to