On Dec 27, 8:15 am, "Rod Dunne" <[EMAIL PROTECTED]> wrote:
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.
I agree entirely that his choice is appropriate in that it makes us aware of the SQLite limitations. On the positive side, it ensures that we JDBC users make informed choices as to how to design our applications. The key problem I see, however, is one of wider adoption. Someone who is new to SQLite/JDBC, and looking to evaluate SQLite by doing a test port of their application to it, would see the lack of full API support as one more impediment along the way, perhaps one that they might not be technically capable of handling. (There are lots of people like that, who are skilled at integrating and configuring Java components into their system, but don't have coding skills.) Worse yet, if they don't have available the source code for their system, there is just no way they can do the port, because they can't change the code. Net effect, they give up on SQLite, which I think is a pity. IMHO, the fewer there are of such impediments to porting, the greater is the possibility of wide acceptance of SQLite. Regards, Sridhar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
