On 7/19/06, Kapil Thangavelu <[EMAIL PROTECTED]> wrote:
The desire is definitely not to have SA automatically remove the
offending object from unit-of-work and continue with the rest. It
would be far too complicated and dangerous given the complex
interdependencies of objects.
But in order that
On Tue, 18 Jul 2006 08:32:05 -0700, Michael Bayer
<[EMAIL PROTECTED]> wrote:
>
> On Jul 18, 2006, at 9:52 AM, Charles Duffy wrote:
>
>> Anyhow, as I was saying, it looks like it should be possible to attach
>> the object to the exception in Mapper.save_obj() so you can find out
>> which object t
On Tue, 18 Jul 2006 05:36:31 -0700, Yuan HOng <[EMAIL PROTECTED]>
wrote:
> On 7/18/06, Charles Duffy <[EMAIL PROTECTED]> wrote:
>> Yuan HOng wrote:
>> > One possibility is to clear the session cache, which however would
>> > mean other valid changes would also be clear out and got lost.
>> > The
On Tue, 18 Jul 2006 06:52:06 -0700, Charles Duffy <[EMAIL PROTECTED]>
wrote:
> With regard to the nested transaction suggestion, I was hoping that this
> would allow an inner transaction to be rolled back after encountering an
> error, such that the outer transaction could continue (which I
> un
On Jul 18, 2006, at 1:12 PM, William K. Volkman wrote:
> I agree that this is perhaps more of an application issue however
> there is some logic that supports the idea that across multiple
> applications the business logic should go into the database.
> What I interpret him asking for is basicall
On Tue, 2006-07-18 at 09:32, Michael Bayer wrote:
> On Jul 18, 2006, at 9:52 AM, Charles Duffy wrote:
>
> > Anyhow, as I was saying, it looks like it should be possible to attach
> > the object to the exception in Mapper.save_obj() so you can find out
> > which object the issue is related to. The
On Jul 18, 2006, at 9:52 AM, Charles Duffy wrote:
> Anyhow, as I was saying, it looks like it should be possible to attach
> the object to the exception in Mapper.save_obj() so you can find out
> which object the issue is related to. The component of what you
> suggested I have serious concerns a
With regard to the nested transaction suggestion, I was hoping that this
would allow an inner transaction to be rolled back after encountering an
error, such that the outer transaction could continue (which I
understand to be the behavior you're wanting, right?). Also, by
segmenting the changes int
On 7/18/06, Charles Duffy <[EMAIL PROTECTED]> wrote:
Yuan HOng wrote:
> One possibility is to clear the session cache, which however would
> mean other valid changes would also be clear out and got lost.
> Therefore I would like SA to inform the application which is the
> object that caused the c
Yuan HOng wrote:
> One possibility is to clear the session cache, which however would
> mean other valid changes would also be clear out and got lost.
> Therefore I would like SA to inform the application which is the
> object that caused the current SQL exception and then remove the
> specific obj
Using echo=True can be helpful for programmers in identifying what
happened. But for a program to to so can be difficult.
It is also difficult to add all check conditions and constraints
current programmed as foreign keys, triggers etc. in the database
itself. Since the database can be accessed b
use echo=True on the SQL is one way. depends on the error, there can
be more pre-flush checks added if they are reasonable.
On Jul 17, 2006, at 12:53 PM, Yuan HOng wrote:
> Suppose in a session a series of objects are modified and new objects
> created, then session.flush() is called to commit
Suppose in a session a series of objects are modified and new objects
created, then session.flush() is called to commit them to database.
Then one or some of them caused an SQL exception, maybe due to some
constaints not being met.
The question is how to identify the offending object? Then the pr
13 matches
Mail list logo
