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
