> Currently, the function will tell yo uthat it failed, although the
> admin site makes very little use of that for reporting. The reason
> for the failure is not available in 1.2.X, and changing the return
> code of these functions (moving from boolean to x-state) is going
> to break existing Midgard applications. I agree that there should
> be a way to know, though.
>
> What does the rest of you think? Especially those who have existing
> Midgard deployments. Another (decidedly less clean) way would be to
> set a global variable (a la errno) to specify the reason for failure.
> Exceptions would be the best way to do it (IMO) but neither PHP or
> the current Midgard concepts are really well suited for it.
>
> emile
If exceptions aren't availabe and return values will break everything, I
have an idea to get around it: _emulating_ exceptions. It's definitely the
hack I would do. It would be accomplished with four global error functions,
not just a variable. Like exceptions, it would allow thorough debugging.
1) The first function, when queried with the name of the function that
failed, would return a struct (preferable) or parseable string similar to:
"function_foo,0; function_bar,456 (X=10)",
so you would be given a chain of errors. Thus if the error in one function
is really an error in another function call made within it, you would know
what's going on, just like with an exception. In this sample, foo had no
internal error (thus code=0 for "Subcall error"), but its call to bar did
(456 = "Out of range"). Bar's error was specifically caused by the
parameter X=10, so it was given.
2) Another global function would allow error reporting. Functions would
give their own name, the error code, optionally any of their parameters (if
relevant), and if the real cause was an error in another function they
called, the name of that function. The chain would be easy to figure out to
hand back to function #1.
3) An error# lookup system. You hand it a code and a target language, it
hands you back a message in that language. So now you have exceptions, in
your choice of language. If the system doesn't have the message mapped in
the language you want, it would either hand you the English version or an
on-the-fly translation (Babel-fish style). The error code messages could
potentially be pulled from a table on the Midgard (or other public) site to
prevent the need to maintain such a database locally.
4) You hand it back the error struct/string you were handed by function #1
and it deletes the corresponding error records.
[optional: 5) Same as #1, but you tell it the target language and it hands
you back the error string with the error codes already turned into text.]
What do you think? Four/five fairly simplistic global functions, lookup
tables giving code meanings, and adding a little chunk of code to existing
functions to let them report what goes wrong.
===============
Emile: on an unrelated note, I don't think ODBC handles anything fancy like
streaming (correct me if I'm wrong, anybody!). ODBC is basically
_Microsoft's_ view of database operations a few years back, so it's fairly
simplistic. If older versions of Sql Server didn't have streaming (and I
doubt they did), ODBC won't either. My guess is that things like streaming
require either native DB operations (fairly easy, but requires mapping to
specific DB's), or an emulation (even more powerful, since it would let you
stream from the FS or from a DB like MySql, but could be a real pain to
code).
-Pat
[EMAIL PROTECTED]
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
