This one time, at band camp, Gustavo Pistoia said:
GP> I'm not neither a database expert nor an oracle guru, so I have to
GP>talk about what my co-workers said. There are a lot of business logic on the
GP>database. Bad point, of course, but cannot be changed now.
GP> They told me there are functions and stored procedures in databases.
GP>Function returns values that must be assigned to a variable, as a part of a
GP>code. Function can make updates, but in this case cannot be done inside a
GP>select, because it may produce an inconsistency. If a function must be
GP>called, it have to be done in script mode. Inside programs, it means to call
GP>it with a callable statement, not as a prepared statement. And that's what I
GP>have to do somehow.
GP> As you can see, it is more complex than a stored procedure. I don't
GP>know if there is a solution now, which could be wonderful. If it's not I
GP>leave it for the future.
My mistake, I know what functions are. I just didn't read the question
correctly.
At this time, functions cannot be used in an OQL statement. Castor's OQL
implementation is currently being refactored to use ANTLR. Once this is
complete, adding functionality to it should be a snap. Therefore, adding
support for passing functions on to a database should be much easier.
Althought it will require some experimentation to figure out how to best
do this.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
