Subject | Re: [IBO] IBO and FB 2 |
---|---|
Author | Dany M |
Post date | 2006-04-24T14:37:53Z |
Geoff Worboys wrote:
[snip]
future. A funny workaround to allow legacy applications right away will
probably backfire later when writing more advanced applications.
I know that I have been using the ability of IBO and the FB 1.5.x API to
return field names and relation names. A query contains a view or a SP
and I can ask what the fields real source was after prepare. Will such
functionality be broken? I have also some logic in my application that
creates alias names on the fly. On some occasions I have used the table
name as alias :(
Going to FB 2 will be very complicated for me either solution that Jason
chooses. But it would probably coax me into better code-writing with a
cleaner solution.
I really think that the FB team should have allowed for a "dialect"-like
possibility to use the old aliasing style.
Regards,
/Dany
[snip]
>The solution should be the one that caters for best practices in the
> Any thoughts from others?
>
future. A funny workaround to allow legacy applications right away will
probably backfire later when writing more advanced applications.
I know that I have been using the ability of IBO and the FB 1.5.x API to
return field names and relation names. A query contains a view or a SP
and I can ask what the fields real source was after prepare. Will such
functionality be broken? I have also some logic in my application that
creates alias names on the fly. On some occasions I have used the table
name as alias :(
Going to FB 2 will be very complicated for me either solution that Jason
chooses. But it would probably coax me into better code-writing with a
cleaner solution.
I really think that the FB team should have allowed for a "dialect"-like
possibility to use the old aliasing style.
Regards,
/Dany