It's perfectly possible to call fb_get_database_handle and
fb_get_transaction_handle to go from new API to legacy API.

Also isc_array_lookup_desc (for example) is implemented as queries in
the client. Not an ideal thing to replicate in new API.

Legacy API is implemented over new API, so in anyway nothing is impossible.

It's not an ideal situation, but I'm against inserting bad, old and
almost unused functions in the new API, and vote for deprecation with
subsequent removal of arrays.


Adriano


On 22/04/2020 08:33, Pavel Cisar wrote:
> Hi all,
>
> I'm writing new Python driver built using new FB3 API (mainly to get
> support for new features not available through old API). I was
> surprised that ARRAY type support in new API is incomplete and thus
> it's not possible to handle this data type in drivers/applications.
> Specifically, the API provides getSlice & putSlice methods on
> IAttachment, but there isn't any equivalent for very important
> isc_array_lookup_bounds function (isc_array_lookup_desc and
> isc_array_set_desc are also missing, but they are not important for
> driver developers).
>
> Alex explained to me, that array support is not functional in new API,
> because core developers are considering to deprecate & remove ARRAY
> type support from future Firebird versions. And because the final
> decision was not made yet, the arrays support in new API get stuck in
> incomplete state.
>
> Personally, I have no problem with deprecation of the ARRAY type, as
> this type is mostly not used (if at all) by Firebird users. Also, I
> understand the reasoning for missing methods that would pollute the
> interfaces with methods that would become eventually obsolete.
> However, I'm really stunned how this issue was handled.
>
> While it's ok to provide only new API for new features (like
> scrollable cursors), the NEW API SHOULD support all old Firebird
> features present in given version and available through old API. And
> ARRAY type is such a feature. Although it's probably not used much by
> Firebird users, it's still used in example EMPLOYEE database that's
> used a lot in books, articles etc., and support for it is available to
> end users via some drivers (like FDB Python driver) for many years. So
> it's definitely POSSIBLE, that users will run into situations when
> lack of ARRAY support will be at least awkward (missing output), if
> not straight fatal.
>
> Argument that one could always use old API to access ARRAYs will not
> stand, because some new features are not available through it, and
> they could not be used together. Users should NOT be forced to choose
> between two API's with distinct features, at least one should be the
> superset (preferably the new one).
>
> Also, if ARRAY type should be ever removed from Firebird, it should be
> done via proper deprecation process (that also includes creation of
> new example database without it). Hence I consider the lack of (at
> least) isc_array_lookup_bounds equivalent in new API as a serious BUG,
> that should be fixed in Firebird 3 & 4. As driver developer I would
> really appreciate if it would be fixed for 3.0.6 due in June.
>
> While ARRAY support is the pressing matter here, there are other old
> API functions that does not have new API replacements (for example
> isc_blob_lookup_desc, and many others). I think that it's the good
> time to compare old and new API's, and create a document that will
> contain table listing the Old API functions with their New API
> counterparts, or explanation why it was decided to not provide such
> equivalent in new API. Such document should be first discussed here
> (so we could decide whether to fix more new API bugs asap), and then
> become a part of Firebird documentation set (as driver developer, I
> was really surprised that such document does not exists yet, as it's
> invaluable for porting from old to new API).
>
> best regards
> Pavel Cisar
>
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to