Yes, I know of it. Krasimir's code uses similar functions and types in the three bindings (MySQL, ODBC, PostgreSql), but the bindings do not share a common interface (AFAICT). Because they are so similar, making them support a common interface shouldn't be a lot of work. I was hoping the earlier discussions on database interfaces would converge to a solution most interested parties agreed on. I'm still sold on the left-fold interface discussed previously. Oleg claims it is sufficient, as it can be automatically converted to a stream-like interface. I bit of me agrees with you that I should be consistent with previous work, and another bit says make it simple and elegant, and this leads me towards Oleg's proposals (left-fold + auto-generated value extraction functions + auto-generated stream functions). Do others on this list (and elsewhere) have any further opinions as to how a database interface ought to look?
-----Original Message----- From: Tim Docker [mailto:timd@macquarie.com.au] Sent: 29 September 2003 13:43 To: Bayley, Alistair; haskell-cafe@haskell.org Subject: RE: Database interface - would like advice on oracle library bind ing
Alistair Bayley wrote:
Still making slow progress on an Oracle database binding... now I'm trying to fit the API I have into some sort of abstract interface (like the one(s) discussed previously:
Since the previous dicussion I've discovered Krasimir Angelov's HSQL interface as part of his HTOOLKIT:
https://sourceforge.net/project/showfiles.php?group_id=65248
This has a uniform abstract interface similar to the one discussed, apparently implemented for MYSQL, ODBC, and PostgreSQL. I've only played with the MYSQL variant.
If possible, it would seem sensible to provide a consistent interface for your Oracle binding. If not, it may be worth persuading him to generalise the interface.
Then again, perhaps you knew about this already.
Tim
***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************