Thanks for the feedback. --- bill lam <[EMAIL PROTECTED]> wrote:
> Just download and look into def.ijs, it appears ucs2/utf16 is not supported > although sqlite seems to support them. Could it be added? Yes, but I think it's feasible only on the level of binding and reading results, i.e. when there is a correspondence between a J string value and an sqlite value. Other things can be added as well, such as what is missing commpared to ODBC is table metadata. > >In general, ODBC in general is increasingly getting > >outdated and needs replacement with a flexible set of > >direct interfaces to Oracle OCI, and other RDBMSes. > > I guess M$ have not annouced any plan to phase out odbc. The main problem is > developers become less interested in writing odbc driver and put resource to > support jdbc and dotnet provider. Unfortunately none of them are directly > callable from J. These are only two, but there are many other similar RDBMS bindings for scripting languages: perl, python, ruby, etc. They can be built very similarly with three layers: direct API, low level provider gluing direct to common low interfaces, and a high-level database interface used by applications. The same can be done for J. Direct API is trivial DLL calls. The overall data interface architecture should squease the provider layer as tight as possible, because that is most of the custom functionality. The thinner it is, the less specific code would be required for each provider. The high level is common for all providers and does not change. For J, the high-level application API makes sense to be array-based with internal iterators representing typical use cases, such as matrix of bulk insert or column result table. If you look at SQLite Addon design, the two upper layers are blended together. But there are some traits of separation, such as the binding provider and result formatters with separate common loop. Different RDBMSs may have different activity transition pattern, which cannot be merely covered with equivalence of function calls. To handle this temporal dimesion, the state processors can be separated from other tasks with callbacks, etc. This state management also relates to error handling and exception unwinding: releasing resources, rollbacks, ignoring vs aborting, etc. Errors make sense to distinuish by where they happen: statement preparation/syntax, execution/integrity/timeout, reading results, etc. A good database API would keep these chores away from application code by providing parametrized state processing with simple declarative interface for various use cases. > -- > regards, > bill __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
