Karl Fogel wrote:
>"Glenn A. Thompson" <firstname.lastname@example.org> writes:
>>I guess I could map them onto DEADLOCK or create other ERRORs. I'm
>>not to thrilled about mapping every error condition into APR
>>space. How about an assessor to set the field?
>I think Greg's point is that we don't have to map every error, we only
>have to map the ones our code checks for.
>And for those, it makes sense to create dedicated SVN_ERR_FOO codes
>anyway -- after all, that was the whole point of that error space, and
>also it's consistent with the way we've been documenting error returns
>so far (e.g., "This returns SVN_ERR_FOO if the file system deadlocks").
I understand his point. But I won't be putting Oracle or MySQL error
codes into APR space. I think it would be confusing. Often times, n
number of errors can be treated as a single condition. That doesn't
mean I want to lose the granularity/information altogether. So I will
check for them in the code and create a svn error. Now, consider a
situation where I have an abstracted framework. Lets say that I trap a
DB error and classify it as x ,y or z in APR error space. I return to
the frame work. He in turn may need to call back to a impl to "handle
the error" after he does some framework stuff. What if the impl error
handler needs more detail?
The bottom line is that I'm OK with the change. If I need this type of
behavior, and I think I will I'll just create an ERROR code like I
mentioned in my later e-mail response. I'll decode it's content if
needed. And it most likely will be needed. With regard to the
DEADLOCK. DEALOCKs are not the only reason a process will be rolled
back in the SQL world. That is why my trail patch changed the
terminology. Another interesting thing is under SQL DBs you don't
always control the "abort" you are rolled back and then told about it.
You can issue a rollback, but you are not always given the choice.
There are also isolation levels and other things which affect when you
get rolled back. At commit, or when the statement is executed.
However, I am confident that I can map SQL onto the trial concept for
my first SQL impl. I'm still not sure whether or not I will use impls
for the "non baseline based" sql impl.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Dec 10 18:19:44 2002