M. A. Sridhar wrote:
Regardless of the technical reasons why, I would think it is important to comply with the (de-facto) standard of the API. Otherwise it becomes an impediment to porting client programs. In my case, I have to look through all references to these method calls and put in special-case code to handle SQLite.
I think I asked David a question like this before. Just because a library adheres to the calling conventions of an API, does not mean that it necessarily follows the spirit or intention of the API. How do blobs actually work in SQLite, sizewise and streaming wise? Perhaps if you really need the streaming capability of very large objects, you would better off writing your own code and saving these blobs as native binary files? I think David is correct in saying that because SQLite does not really do the things under the hood that people expect from the blob API, then why bother implementing that, when he already has implemented set and getBytes etc. His choice is to force you to deal with compile time problems, rather than run time problems, and I believe most people would prefer that. Cheers. Rod. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLiteJDBC" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups-beta.google.com/group/sqlitejdbc?hl=en -~----------~----~----~----~------~----~------~--~---
