Re: [sqlite] A proposal for SQLite version 3.0
Echoing some others' responses, particularly Darren's:
1. I don't see the rationale for putting much priority on
multiple string encodings. After all, blobs still can't
be stored natively :).
UTF-16 adds extra complexity, because of embedded nulls,
and because of its own need for a byte-order-mark (BOM).
Furthermore, it is not a fixed width encoding.
(Java, and Windows prior to win2k, behaved as it if it was
fixed length, by neglecting surrogate pairs, but they are
just broken.)
UTF-8 is not a fixed width encoding either, but it does
not have embedded nulls, and it is supported "natively" by
practically all scripting languages.
The wchar_t issue is a pain; on Windows it is typically
a 16-bit type, and on Unix it is typically 32-bit, and in
either case you still don't know whether it is UCS-2, UTF-16,
or (on unix) UCS-4.
But using a char* declaration for a string that can contain
embedded nulls is an invitation to rampant bugs, IMHO.
2. I would be very interested to hear more about better
concurrency support, particularly along the lines of
the HUT HiBase/Shades ideas.
Doug Currie has written up some ideas about this in
cvstrac ("BlueSky"), but I'd also urge people to read
the HUT papers. At least K. Oksanen's publications are
still online at http://hibase.cs.hut.fi/publications.shtml
3. I'm unsure what is driving a desire for variable typing
among the values of a single column. Is this some deep-seated
distaste for the relational model :).
-mda
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
I think the collate feature will solve this. have a pre-defined collate TEXT_CI is the solution. One thing Microsoft allows you to do is create a database with a defined collation. Maybe this is the idea around the parameters in the open API . You could open a DB with COLLATION TEXT_CI and it would collate using the open parameter by default. If there was a column override then it would use that Greg - Original Message - From: Darren Duncan To: [EMAIL PROTECTED] Sent: Monday, April 12, 2004 8:46 AM Subject: RE: [sqlite] A proposal for SQLite version 3.0 At 11:22 PM +0100 4/11/04, Steve O'Hara wrote: >I agree with Greg, the most irksome feature of SQLite is the case >sensititvity - it's one of the few things MS got right with SQLserver. I >know this is more mainstream/standard SQL behaviour but it's outdated in >modern SQL applications that nearly always do some kind of linguistic >searching. >In fact, I'd go one step further and advocate making SQLite case-insensitive >as a rule. >I'm waiting for the flames... >Steve As far as I'm concerned, the issue of case-sensitive vs insensitive is related to locale or nationality specific matters. It involves treating a pair of different characters as being the same character. Besides our latin characters, does any other written language have such a concept as upper/lowercase? Whichever is available will probably have its fans. Case-insensitive may be more like a "natural human language" whereas the other may be less, or not. I think that both methods should be supported, perhaps with a compile time directive determining the default, and a run-time directive changing it on a case by case basis. One thing to make absolutely certain, though, is that the SQLite API provides a means to programmatically determine at runtime what behaviour is being used. If nothing else, it allows an application which either expects one behaviour or is able to adapt to either, to know how to talk to the database such that its expectations match reality. Personally, I would hate for an application which expects a case-sensitive unique field, and inserts multiple rows that it thinks are distinct, only to have one fail or overwrite the other because some case-insensitive rule says they are actually the same. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Hi Will, Thanks for clearing that up for me, it make more sense now. Greg - Original Message - From: Will Leshner To: Forum SQLite Sent: Monday, April 12, 2004 8:06 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk wrote: > You state that there may or may not be the call-back function wrapper. > I would be an advocate for keeping it. This way of handling returned > data is most useful. Sometimes when returning thousands or more rows > of data you want to cancel the statement without a call-back function > you must wait until the statement is finished and then discard the > result. Having a call-back allows you (or the user) to terminate the > statement. > With the non-callback-API, "executing" the query simply returns a virtual machine ready to get query results. It doesn't actually return any results. You then have to step through the results yourself. So you can pretty much stop the query any time you'd like. And the callback mechanism is now built on top of the non-callback mechanism anyway, so you wouldn't be able to do anything with callbacks you couldn't do without them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] A proposal for SQLite version 3.0
I agree with Greg, the most irksome feature of SQLite is the case sensititvity - it's one of the few things MS got right with SQLserver. I know this is more mainstream/standard SQL behaviour but it's outdated in modern SQL applications that nearly always do some kind of linguistic searching. In fact, I'd go one step further and advocate making SQLite case-insensitive as a rule. I'm waiting for the flames... Steve -Original Message- From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] Sent: 11 April 2004 23:02 To: D. Richard Hipp; [EMAIL PROTECTED] Subject: Re: [sqlite] A proposal for SQLite version 3.0 Hello, I just read the proposed changes and they seem fine. A couple of thing. The data types I think are great but can we have a large and small integer? I noticed some people (embedded systems people) complain about this. I quite happy with the large type but as integers will now be stored as the native type that will double the storage requirement for numbers (64-bit integer taking 8bytes where 32 take 4bytes) So may be something like if the value is a number then check to see if it fits in a 32bit integer if it does use that otherwise use a 64 bit. If this is too much trouble in code then maybe a compile directive to use a certain size integer. When using a INTEGER PRIMARY KEY perhaps we could use INTEGER SMALL PRIMARY KEY and INTEGER LARGE PRIMARY KEY Support for user definable collating. I'm assuming that this will give us the ability to turn SQLite into a non case sensitive system by defining our own collation which is not case sensitive? Which is great and you state that there will be two predefined collations COLLATE TEXT and COLLATE NUMERIC. Can I suggest that you create a third pre-defined collation (to make it easy on us that want it) can you create a COLLATE TEXT_CI . Which would be a case in-sensitive collation. Then the people that really want this can use it off the bad, as it were. I'm sure it will be a lot easier for you to create it that for someone else. API and preferred way of executing queries I'm assuming there will still be the wrapper to execute a SQL in one line . You state that there may or may not be the call-back function wrapper. I would be an advocate for keeping it. This way of handling returned data is most useful. Sometimes when returning thousands or more rows of data you want to cancel the statement without a call-back function you must wait until the statement is finished and then discard the result. Having a call-back allows you (or the user) to terminate the statement. Apart from that great changes , more complete but things change and grow (which is good). If I had to decide which is my most wanted feature from the stuff above I would say COLLATE TEXT_CI as this would enable me to use = instead of LIKE in my lookups (I really don't like case sensitive data in the real world) kind regards Greg O - Original Message - From: D. Richard Hipp To: [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 11:22 PM Subject: [sqlite] A proposal for SQLite version 3.0 A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk wrote: You state that there may or may not be the call-back function wrapper. I would be an advocate for keeping it. This way of handling returned data is most useful. Sometimes when returning thousands or more rows of data you want to cancel the statement without a call-back function you must wait until the statement is finished and then discard the result. Having a call-back allows you (or the user) to terminate the statement. With the non-callback-API, "executing" the query simply returns a virtual machine ready to get query results. It doesn't actually return any results. You then have to step through the results yourself. So you can pretty much stop the query any time you'd like. And the callback mechanism is now built on top of the non-callback mechanism anyway, so you wouldn't be able to do anything with callbacks you couldn't do without them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Hello, I just read the proposed changes and they seem fine. A couple of thing. The data types I think are great but can we have a large and small integer? I noticed some people (embedded systems people) complain about this. I quite happy with the large type but as integers will now be stored as the native type that will double the storage requirement for numbers (64-bit integer taking 8bytes where 32 take 4bytes) So may be something like if the value is a number then check to see if it fits in a 32bit integer if it does use that otherwise use a 64 bit. If this is too much trouble in code then maybe a compile directive to use a certain size integer. When using a INTEGER PRIMARY KEY perhaps we could use INTEGER SMALL PRIMARY KEY and INTEGER LARGE PRIMARY KEY Support for user definable collating. I'm assuming that this will give us the ability to turn SQLite into a non case sensitive system by defining our own collation which is not case sensitive? Which is great and you state that there will be two predefined collations COLLATE TEXT and COLLATE NUMERIC. Can I suggest that you create a third pre-defined collation (to make it easy on us that want it) can you create a COLLATE TEXT_CI . Which would be a case in-sensitive collation. Then the people that really want this can use it off the bad, as it were. I'm sure it will be a lot easier for you to create it that for someone else. API and preferred way of executing queries I'm assuming there will still be the wrapper to execute a SQL in one line . You state that there may or may not be the call-back function wrapper. I would be an advocate for keeping it. This way of handling returned data is most useful. Sometimes when returning thousands or more rows of data you want to cancel the statement without a call-back function you must wait until the statement is finished and then discard the result. Having a call-back allows you (or the user) to terminate the statement. Apart from that great changes , more complete but things change and grow (which is good). If I had to decide which is my most wanted feature from the stuff above I would say COLLATE TEXT_CI as this would enable me to use = instead of LIKE in my lookups (I really don't like case sensitive data in the real world) kind regards Greg O - Original Message - From: D. Richard Hipp To: [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 11:22 PM Subject: [sqlite] A proposal for SQLite version 3.0 A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [sqlite] A proposal for SQLite version 3.0
=== On 2004-04-09, D. Richard Hipp wrote === .. > >The reason for not doing this is that maintenance of the counter >slows down inserts and deletes. Is having a constant-time count(*) >really work slower inserts and deletes? If you have opinions on >this, speak up now, because it won't be an option later. > I have no idea of the complexities internal to SQLite (I'm just sure it is complex ;), but its a variable that only needs update on inserts and deletes, when the database is locked for writing. It will add a file page page that needs to be updated to disk, but as it will always be the same page would not that be negligible compared with the time needed for parsing and writing the others expressions? As it is the same page it will always be possible for the OS to cache it. The typical use of the COUNT(*) expression is when displaying results in a grid. One needs to know how many rows are so it can use the LIMIT expression later to just fetch a page at a time (and to know in advance the number of pages). If we use a trigger to emulate this row count I'm sure the penalty for insertion/deletion would be much worse. I have full confidence on your work, so what you decide is enough for me. Regards, ~Nuno Lucas P.S.- Everytime I post something I receive two copies of the message I posted and a warning message for every recipient in the list that isn't available anymore. Could someone please check it out? Thanx. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Windows UTF-16 is represented by WCHAR. It is always 2 bytes. UCS-2 can be 3 or more bytes but these are for extended characters outside the ones used for real language. For example, musical notation symbols use the third byte. I don't think any OS's use UCS2 directly. I know Oracle supports UTF8, UTF16, and UCS2. In fact, Oracle's online documentation has a really good discussion of Unicode. Look for their internationalization book. I wrote some code that was sharing data from Oracle to Microsoft SQL Server and found this book very helpful. Oracle generally favors UTF8 while SQL Server favors UTF16. http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/toc.htm If you are going to cast to unsigned char*, you must manage the fact that your strings are two (or more) bytes. You are just effectively using a byte pointer to the string data. I think wchar_t* is used typically but the encoding is usually platform dependent. The big problem you have is that your databases are portable. I think you will need to pick and internal format to store the strings in the db so that you can then translate as appropriate for a platform. You may be able to do some clever things like use sizeof(wchar_t) to find out how many bytes are used for a character and use that for your translation. There is a Unicode book available that talks about the specs. Unfortunately, my experience has been that everyone has their own nuiances. Generally though it is pretty consistent. -- Andrew On Wed, 7 Apr 2004, D. Richard Hipp wrote: > Simon Berthiaume wrote: > > >> Notice that text strings are always transferred as type "char*" even > > if the text representation is UTF-16. > > > > This might force users to explicitely type cast some calls to function > > to avoir warnings. I would prefer UNICODE neutral functions that can > > take either one of them depending on the setting of a compilation > > #define (UNICODE). Create a function that takes char * and another that > > takes wchar_t * them encourage the use of a #defined symbol that would > > switch depending on context (see example below). It would allow people > > to call the functions in either way they want. > > > > Example: > > > > int sqlite3_open8(const char*, sqlite3**, const char**); > > int sqlite3_open16(const wchar_t*, sqlite3**, const wchar_t**); > > #ifdef UNICODE > > #define sqlite3_open sqlite3_open16 > > #else > > #define sqlite3_open sqlite3_open8 > > #endif > > > > I'm told that wchar_t is 2 bytes on some systems and 4 bytes on others. > Is it really acceptable to use wchar_t* as a UTF-16 string pointer? > > Note that internally, sqlite3 will cast all UTF-16 strings to be of > type "unsigned char*". So the type in the declaration doesn't really > matter. But it would be nice to avoid compiler warnings. So what datatype > are most systems expecting to use for UTF-16 strings? Who can provide > me with a list? Or even a few examples? > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
I'm assuming UTF-8 support will still be there as well? For Windows applications, UTF-16 is much more prevalent. -- Andrew On Wed, 7 Apr 2004, Christian Smith wrote: > On Wed, 7 Apr 2004, D. Richard Hipp wrote: > > >A design proposal for SQLite version 3.0 can be found at: > > > > http://www.sqlite.org/prop2.html > > > >Feedback from the user community is strongly encouraged. > >An executive summary of the proposed changes follows: > > > >* Support for UTF-16 > > > >I do not have much experience with UTF-16 and am > >expecially interested in feedback on that area of > >the design. > > > > For better or for worse (I've not much experience myself) other systems > use wchar to represent UTF-16 strings, so it might be worth adopting that > convention. This may cause problems, though, as we'd have to check if > wchar is defined, and typedef it ourselves if not. > > If you're going to be changing the function prefix to sqlite3_, then it > might also be worth changing the header file to sqlite3.h as well, that > way we can also provide a seperate sqlite.h which wraps the sqlite3 API in > the old API. I'd prefer that than being able to use the two library > versions at the same time. > > Is there much call for a binary to use two versions of the library at the > same time? Surely the proper dump/restore as discussed a few weeks would > be better for data compatibility? > > Cheers, > Christian > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
D. Richard Hipp wrote: > The 1st and 3rd APIs above will work, but not the second. Remember, > SQLite 3.0 will have manifest typing, which means that type of the > data can change from one row to the next. Type is not associated > with a column, as in standard SQL. So there is no way to know the > type in advance. > > Manifest typing is a feature, not a bug. The static typing design > of SQL is the bug. ;-) I wasn't sure how much type information SQLite gathered about the literals it needs to be assigned to parameters. If there is none, then this API doesn't make much sense after the statement is prepared, but it is still needed to determine the parameter's type after it has been bound to a particular value (with a manifest type). That type may be needed to call the correct parameter data readback function. > Someone earlier suggested that the same named parameter could occur > in multiple places in the input SQL, but you should only have to bind > it once. That argument makes sense to me. But allowing multiple > occurrences of the same named parameter means that the name->index map > is not unique so the function above will not work. The name to index mapping must be unique and one-to-one. The idea is to have a single parameter value with a name that may appear multiple times in the SQL statement. Every occurrence of that name in the statement is replaced with the bound value when statement is executed. That is why SQLite must scan the parameter list each time it parses a parameter name in the statement. It must check if it has already assigned an index number to this name, or if it needs to assign a new index number for a new name. The index numbers are used internally in the VDBE code that is generated to execute the statement. The client application then only needs to bind the value of the parameter once, not once for each time it appears in the original SQL statement. > Is that really the desired behavior? If you want to reset parameters > on a statement reset, wouldn't it be better to do so explicitly. That > way, if a statement has 10 parameters, and you want to execute it 10 > times, and only one parameter changes between each run, you do not > have to reinitialize the other 9 every time. No, that's what happens when you add a quick comment without giving it enough though. You are right, it makes much more sense to leave all parameters with there current value after a reset. If the user want to change any value they can use the bind API to change just the parameters that need to change, and they can set them to null if they want. This way only the values that need to change are modified, rather than having SQLite change them to null, and the user change many of them back to their previous value. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] A proposal for SQLite version 3.0
> > > > A statement's parameter values would be reset to null > values when the > > statement is reset. > > > > Is that really the desired behavior? If you want to reset > parameters on a statement reset, wouldn't it be better to do > so explicitly. That way, if a statement has 10 parameters, > and you want to execute it 10 times, and only one parameter > changes between each run, you do not have to reinitialize the > other 9 every time. > You could add an option to the reset function to specify whether the parameters should be reset. Tim McDaniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Dennis Cote wrote: The API should provide functions that allow the application to inspect the number, type, and names of the parameters that were discovered while parsing the SQL. These functions could be called any time after the statement is prepared. int sqlite3_param_count(sqlite3_stmt* stmt); int sqlite3_param_type(sqlite3_stmt* stmt, int iParm); const char* sqlite3_param_name(sqlite3_stmt* stmt, int iParm); The 1st and 3rd APIs above will work, but not the second. Remember, SQLite 3.0 will have manifest typing, which means that type of the data can change from one row to the next. Type is not associated with a column, as in standard SQL. So there is no way to know the type in advance. Manifest typing is a feature, not a bug. The static typing design of SQL is the bug. ;-) You have the value data pointers declared as static char and void pointers. I believe they should be const pointers. You're right. A typo. I would propose adding a second set of parallel API functions that would allow the application to bind the parameters by name for those cases (likely far more common) where the application knows the names of the parameters beforehand This second set of these bind functions could be eliminated by the use of a single new API function that would return the index for a parameter given its name. int sqlite3_param_index(sqlite3_stmt* stmt, const char* name); Someone earlier suggested that the same named parameter could occur in multiple places in the input SQL, but you should only have to bind it once. That argument makes sense to me. But allowing multiple occurrances of the same named parameter means that the name->index map is not unique so the function above will not work. A statement's parameter values would be reset to null values when the statement is reset. Is that really the desired behavior? If you want to reset parameters on a statement reset, wouldn't it be better to do so explicitly. That way, if a statement has 10 parameters, and you want to execute it 10 times, and only one parameter changes between each run, you do not have to reinitialize the other 9 every time. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
D. Richard Hipp wrote: > A design proposal for SQLite version 3.0 can be found at: > > http://www.sqlite.org/prop2.html > Richard, I read your proposal and it all look very promising to me. I would like to propose some additions to the API to support named parameters in the SQL statement. These features will make it easier to use parameters in complex SQL statements, and also allow generalized handling of SQL statements in cases where the statement to be executed is not know before it is executed (this occurs with manually entered SQL in database "explorer" applications for example). It also makes the use of pre-prepared SQL more straight forward. First I would propose that SQLite recognize named parameters in the SQL code. A named parameter is a colon, ':', followed by the parameter name. The name itself must be a valid SQL identifier, like table and column names. Some example names are; :foo, :bar, :part_number, and :zip_code. SQLite would recognize the named parameters when the statement is parsed by the prepare API function. SQLite will maintain a list of parameters found in the statement. As each parameter name recognized, SQLite will scan the list of parameters to see if this name has appeared earlier in the statement. If so it will use the previously assigned index for that parameter. If not, it will add the new parameter name to the end of the list (effectively assigning it the next index value). The API should provide functions that allow the application to inspect the number, type, and names of the parameters that were discovered while parsing the SQL. These functions could be called any time after the statement is prepared. int sqlite3_param_count(sqlite3_stmt* stmt); int sqlite3_param_type(sqlite3_stmt* stmt, int iParm); const char* sqlite3_param_name(sqlite3_stmt* stmt, int iParm); The first function returns the number of parameters in the statement. The second returns the type code of the indexed parameter. This function would use the same type codes as the sqlite3_column_type function. The third would return the name (without the colon prefix character) of the parameter. The parameter names may be used to build a menu of parameters for a user to fill in before the statement is executed. The application could use the currently proposed bind functions to bind a value to the parameter. int sqlite3_bind_int32(sqlite3_stmt*, int iParm, int value); int sqlite3_bind_int64(sqlite3_stmt*, int iParm, long long int value); int sqlite3_bind_double(sqlite3_stmt*, int iParm, double value); int sqlite3_bind_null(sqlite3_stmt*, int iParm); int sqlite3_bind_text(sqlite3_stmt*, int iParm, const char* value, int length, int eCopy); int sqlite3_bind_text16(sqlite3_stmt*, int iParm, const char* value, int length, int eCopy); int sqlite3_bind_blob(sqlite3_stmt*, int iParm, const void* value, int length, int eCopy); I noticed a error in the prototypes for the bind text and blob API functions in the proposal. You have the value data pointers declared as static char and void pointers. I believe they should be const pointers. I would propose adding a second set of parallel API functions that would allow the application to bind the parameters by name for those cases (likely far more common) where the application knows the names of the parameters beforehand. This way the application can bind to the parameters by name without being forced to use the parameter inspection functions to determine the parameter indexes. This would also be resistant to errors introduced by reordering the parameters while editing the SQL statement without reordering the bind calls. int sqlite3_bind_name_int32(sqlite3_stmt*, const char* name, int value); int sqlite3_bind_name_int64(sqlite3_stmt*, const char* name, long long int value); int sqlite3_bind_name_double(sqlite3_stmt*, const char* name, double value); int sqlite3_bind_name_null(sqlite3_stmt*, const char* name); int sqlite3_bind_name_text(sqlite3_stmt*, const char* name, const char* value, int length, int eCopy); int sqlite3_bind_name_text16(sqlite3_stmt*, const char* name, const char* value, int length, int eCopy); int sqlite3_bind_name_blob(sqlite3_stmt*, const char* name, const void* value, int length, int eCopy); This second set of these bind functions could be eliminated by the use of a single new API function that would return the index for a parameter given its name. int sqlite3_param_index(sqlite3_stmt* stmt, const char* name); Using this function and one of the index based bind functions together would accomplish the same thing, but it may introduce slightly more overhead due to repeated checking of the statement pointer etc. This function could return an invalid index of zero if the name does not match any of the parameters for the statement. I think the invalid, zero, index approach should be quite safe since the bind functions will need to check and report the invalid index through its error
RE: [sqlite] A proposal for SQLite version 3.0
The proposal for version 3.0 looks very promising and I hope all the major changes will be implemented. Most of the enhancements seem to add flexibility and scalability to to the "C" based api. This is great as at the "C" api call level you can do anything you want. But I do not see any changes to add similar flexibility at the SQL language level. Declarative programming is much more productive than writing many lines of "c" code to do any data manipulation tasks. The current SQL language implementation excels at the vast majority of data manipulation needs but falls short in being able to implement a complete data management system at the SQL language level. One example is creating a database. SQLite can only create a database at the "c" api level. This should be changed to be able to use a CREATE DATABASE command. The sqlite3_open function should be implemented with one major change. Instead of passing the complete file name of the database, pass in the name of the directory where the master/system database will be created/opened. Only the master/system database should be created automatically if one is not located in that directory. A sqlite3_create function as well as a CREATE DATABASE command would create a user database in the same directory as the master/system database by default as the system database would contain a list of all user database that have been created under that system database. Once a database has been created, a USE command would open that database if it is found in the master/system database and make this the current database. The DETACH command could then delete the user database link into the master/system database and this user database would then be free to ATTACH to another master/system database. Once this functionality is implemented it should not be hard to implement a sqlite_users table in the master/system database to holder user information so the GRANT/REVOKE command could be implemented against any user database listed in the master/system database. All of the above is based on the simple command of creating a database at the SQL language level. Many other enhancements to the SQL language could/should be implemented and I would gladly make more suggestions if any other current users of SQLite feel that this would be a good step forward B.Thomas -Original Message- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 9:22 AM To: [EMAIL PROTECTED] Subject: [sqlite] A proposal for SQLite version 3.0 A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
Re: [sqlite] A proposal for SQLite version 3.0
Yes, that is right, my database consists of mainly numbers. Some of them have 10 digits, some have less. This would explain part of the difference. I was also wondering if Access perhaps has some type of index comprimation, like cutting pre- and postfixes in the B-tree. Jakub Simon Berthiaume wrote: It might be true if you mostly store large quantities of NUMERICAL data (float, int, ...) since they are currently stored as strings (the value 1234567, would be stored using at least 7-8 bytes instead of 4). If you were in the same situation as I, where I use database mostly for strings, you would be in the opposite situation, the SQLite database would be about half the size of the MS Access one, since MS Access seems to save all strings as UTF-16. Simon B. On Wed, 2004-04-07 at 10:50, Jakub Adamek wrote: Hello, I am using SQLite in a car navigation system which should work on PDAs as well. Thus speed and size is crucial for us. SQLite is superb in the speed category, but the size of its file is not so superb. I see you mentioned something about file size. My experience is that SQLite makes roughly about 3x bigger files than MS Access. How would this change in 3.0? Thanks for your excellent work, Jakub Adamek D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
> Could we please see the current behaviour set in stone? I'd like to know > that generated keys will always fit into 32 bits (provided I don't > exceed ~4.3 billion records, naturally). I think that it's a dangerous precent to fix these things in stone, certainly at the source level. Perhaps, should it become a concern, offer the option at compile time to have 32/64/n bit keys. Far too often I've seen stone-cast items such as this become the agony of others. Paul. -- Paul L Daniels - PLD Software - Xamime Unix systems Internet Development A.B.N. 19 500 721 806 ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73 PGP Public Key at http://www.pldaniels.com/gpg-keys.pld - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
I have an application which depends on INTEGER PRIMARY KEY values fitting into 32 bits. I know that currently, the keys are generated with MAX()+1, but this behaviour is "undocumented and liable to change.: Now that rowid's are going 64 bit, a truly random INTEGER PRIMARY KEY may not fit into 32 bits. Could we please see the current behaviour set in stone? I'd like to know that generated keys will always fit into 32 bits (provided I don't exceed ~4.3 billion records, naturally). Thanks -- Andrew Francis Lead Developer Family Health Network - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] A proposal for SQLite version 3.0
Null is not a value. The definition of NULL is that a value has not been assigned and is therefore unknown. Once a value is assigned, Null is no longer valid. Unless somebody changed the definition in the last thirty years or so :-) > -Original Message- > From: Tom Shafer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 9:09 PM > To: [EMAIL PROTECTED] > Subject: [sqlite] A proposal for SQLite version 3.0 > > > Vote for a database parameter:IS NULL A VALUE ? YES or NO > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote: A little while ago a list reader suggested a kind of index (from ms access, if I recall... I don't recall the term they used) that is not external. Instead the index changes the order in which the table itself is organised. I believe you're thinking of a 'clustered index'. This puts the data into the order of the index. There can be, of course, only one clustered index per table. Since at least some of the data in the table is moved around on every insert, regular indexs need to take this into account (usually by indirection, rather then modifying all of the indexes with each insert). If a table could be ordered according to an index, rather than having an external index, I think it would significantly improve the time and space performance of my databases. I don't know whether my experience would be shared by other users. It it were something that could go into 3.0 it would at least do me some good. I'm not sure it would be good for your application. Clustered indexes are good for OLAP (On-Line Analytical Processing) and other systems where data is rarely inserted (or is inserted in batches at off-hours) and most of the interactive activity is selects (with very few inserts). Clustered indexes can really slow the performance for OLTP (On-Line Transaction Processing) and other systems where data is added/deleted in a mixed fashion. Every time a record is inserted, data is possibly moved on the disk (with page splits causing even more slowdowns). If your system is entirely historic data, that would be great - but if your system is inserting meter readings in (near) real-time, you'd probably get a big performance hit. There are many pros and cons. A google search turns up articles (usually for MS SQL Server) on both side - some people saying 'always' and some 'never'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Peoples :) "D. Richard Hipp" <[EMAIL PROTECTED]> 07/04/2004 11:22 PM To: [EMAIL PROTECTED] cc: Subject:[sqlite] A proposal for SQLite version 3.0 > A design proposal for SQLite version 3.0 can be found at: > http://www.sqlite.org/prop2.html > Feedback from the user community is strongly encouraged. Since this is a fairly rare opportunity to make incompatible suggestions that could make it into code, I thought I'd put this left-field one out there: My main use of sqlite is in a database that stores vast quantities of historical data (individual changes on meter readings, that sort of thing). The main table contains data for multiple instruments that each provide their data in time order with their own updates, but out of order with the updates of others: Instrument1,2am,value is 0 Instrument2,1:59am,value is 3 Instrument1,3am,value is 1 Instrument2,3:01am,value is 4 This table is constructed in the order that data comes in, but the queries I want to do are quite different: SELECT * FROM thetable WHERE instrument="Instrument1" AND time >= 2am and time <= 3am ORDER BY TIME; Well, I have an index to make this work efficiently (the exact query and index details probably aren't that important here). The problem is that the index contributes significantly to the size of the database and the fact that I keep the original ordering around but unused seems like a waste of effort. Queries are also slower than they would be if they were following an integer primary key along a real table, with the extra O(log(n)) lookup for each result entry. A little while ago a list reader suggested a kind of index (from ms access, if I recall... I don't recall the term they used) that is not external. Instead the index changes the order in which the table itself is organised. You suggested at the time that if explicit ordering were required the user could use a CREATE TABLE AS SELECT statement to get things in that order, but that sqlite would have to table-scan as it would have no saved knowledge of the table ordering. Moreover the table would not remain ordered as new elements were ordered. If a table could be ordered according to an index, rather than having an external index, I think it would significantly improve the time and space performance of my databases. I don't know whether my experience would be shared by other users. It it were something that could go into 3.0 it would at least do me some good. The other thing that I think will help me most is the native storage of numeric formats. It's great to see this happening :) On the wchar_t subject, I've just looked up http://docs.sun.com/db/doc/806-0477/6j9r2e2bp?a=view, which says wchar_t is a long under 32-bit solaris and int under 64-bit solaris. Both numbers are 32-bits long. According to http://en.wikipedia.org/wiki/UTF-32, a 32-bit representation is the only unicode that is actually fixed-width. Both UTF-8 and UTF-16 are multi-byte, rather than wide characters. This page also lists various known unicode encodings, so may be of some value. Benjamin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Darren Duncan wrote: Here are some of the things I like (correct me if any actually not present): Your summary looks very good. Thanks you. - SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE. - Actual blobs can be stored and fetched without any nasty encoding/decoding. Version 2.8.13 already supports this, BTW. Version 3.0 will continue the support. - Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value). SQLite has had this property going back to version 1.0. The distinction is lost in the wrappers to many scripting languages. But that isn't really SQLite's fault. I do not see UTF-16 providing any speed benefits in regards to being 'the same' as internal Unicode representations for various operating systems like Windows or Mac OS X; true, it may match some OSs, but for others you will need just as much work or speed penalty to convert from UTF-16 to what the operating system uses and from UTF-8. Of course, you may already know this and the disk/memory usage leveling may be the main reason you support UTF-16. The internal representation of text can be either UTF-8 or UTF-16 (either byte order). The text representation is fixed when the database is created. If you are dealing primarily with UTF-8 text, it makes sense then to create the database so that it uses UTF-8 internally. Similarly, create databases to use UTF-16 internally if that is your primary usage. That way conversions are minimized. Regardless of the internal representation, text can always be accessed as either UTF-8 or UTF-16. If what you want does not match the internal representation, an automatic conversion occurs. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
eno wrote: well, the question is: Support UTF-16 to what extent? I think here of sorting questions, (but other may arise). Obviously, sorting within a single language is specific to that language, whereas sorting a, say, german word with an ukrainian word is what a programmer calls "undefined". And comparing two german words - according to the rules a german user would expect - might be different from what a default comparison routine would return. The programmer can use sqlite3_create_collation() to register collating sequences for any languages she wants. You can then say things like: SELECT addr FROM phonebook ORDER BY name COLLATE german; CREATE INDEX idx1 ON phonebook(name COLLATE ukrainian); CREATE TABLE phonebook( name1 TEXT COLLATE french, name2 TEXT COLLATE japanese, addr TEXT ); Unlike client/server databases which much provide a predefined set of sort orders, SQLite provides a single simplistic sort order plus the capability for the programmer to add whatever other sort orders are desired. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
At 9:22 AM -0400 4/7/04, D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. Hey, this looks great! Here are some of the things I like (correct me if any actually not present): - New features in 3.0, 2.x maintained for bug fixes only. - Altered "sqlite3_" API prefixes to simplify app binding to both versions. - Principle of break everything at once (same one used with Perl 6 design). - API backward compatability with 2.x relegated to external wrapper layer. - Unicode is now the native text representation, and only option for files. - All internal code from pager layer on up is natively/conceptually big-endian only, with big/little distinctions made at OS layer or other periphery. - SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE. - Actual blobs can be stored and fetched without any nasty encoding/decoding. - Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value). - Actual integers and floats which are 64 bits, when program wants *numbers*. - Default collating output of NULLs followed by numbers, by blobs, by text. - Ability to use binary values in indexes. - All "unqualified" function APIs expect UTF-8 for text by default, where UTF-16 has separate functions with '16' added to their names. - Smaller and faster than 2.x. - Removal of deprecated callback interface. Here are some improvements or suggestions that I can make: - Provide support for named inspecific literal placeholders in SQL rather than only positional ones, which the "?" are. I think that some other database engines use placeholder names like ":foo" and ":bar" so you could do it that way. These are useful because the SQL code and corresponding bind function calls are a lot more self-documenting, and less prone to programmer errors (alignment errors) when making or changing longer SQL statements with lots of placeholders. Another advantage is that when the same inspecific literal value is used multiple times in the same SQL statement, as often happens, it only needs to be bound or copied by the API once. Note that for simplicity or efficiency the named and positional versions should both be available, and be mutually exclusive (eg: someone could use both at once without conflicts). - While you are good to have support for it, I'm not sure I recognize a great amount of value that UTF-16 provides over UTF-8. More specifically, the main benefit I see UTF-16 providing is a more efficient use of disk space or memory when our data has a lot of non-latin characters in it; in that respect it tends to level the playing field resource-usage-wise for people in all parts of the world. However, I do not see UTF-16 providing any speed benefits in regards to being 'the same' as internal Unicode representations for various operating systems like Windows or Mac OS X; true, it may match some OSs, but for others you will need just as much work or speed penalty to convert from UTF-16 to what the operating system uses and from UTF-8. Of course, you may already know this and the disk/memory usage leveling may be the main reason you support UTF-16. - You mentioned in one line about doing something with the recent concurrency proposal discussion. Obviously this will have to be fleshed out inside the proposal before it can be commended on as feedback. I probably forgot some of what I was going to say in this feedback, so maybe later. Note also that I am not reading anyone's responses to DRH's initial post and proposal until after I post this, so that my impressions of the original proposal are not tainted by them. So thanks DRH, and keep up the good work. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
It might be true if you mostly store large quantities of NUMERICAL data (float, int, ...) since they are currently stored as strings (the value 1234567, would be stored using at least 7-8 bytes instead of 4). If you were in the same situation as I, where I use database mostly for strings, you would be in the opposite situation, the SQLite database would be about half the size of the MS Access one, since MS Access seems to save all strings as UTF-16. Simon B. On Wed, 2004-04-07 at 10:50, Jakub Adamek wrote: > Hello, > > I am using SQLite in a car navigation system which should work on PDAs > as well. Thus speed and size is crucial for us. SQLite is superb in the > speed category, but the size of its file is not so superb. I see you > mentioned something about file size. My experience is that SQLite makes > roughly about 3x bigger files than MS Access. How would this change in 3.0? > > Thanks for your excellent work, > > Jakub Adamek > > D. Richard Hipp wrote: > > > A design proposal for SQLite version 3.0 can be found at: > > > > http://www.sqlite.org/prop2.html > > > > Feedback from the user community is strongly encouraged. > > An executive summary of the proposed changes follows: > > > >* Support for UTF-16 > >* Better BLOB support > >* User-defined collating sequences (for better > > internationalization support) > >* Smaller and faster than 2.8.13. > > > > The plan is to continue to support the 2.8.X series > > indefinately and in parallel to the 3.X series. But > > the only changes to 2.8.X going forward will be bug > > fixes. New features will go into 3.X. Beta releases > > of version 3.X are expected within a few months. > > > > I do not have much experience with UTF-16 and am > > expecially interested in feedback on that area of > > the design. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: [sqlite] A proposal for SQLite version 3.0
Wouldn't this be due to SQLite storing everything as strings? If your database is predominantly numbers then I imagine the differences between Access and SQLite could be huge. Steve -Original Message- From: Roy Black [mailto:[EMAIL PROTECTED] Sent: 08 April 2004 04:38 To: [EMAIL PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another way, about 60% to 75% of an SQLite database file is the actual data being stored and the other 40% to 25% is overhead. If you have an example where the overhead is significantly larger than this, I'd be interested in seeing it. The new version 3.0 file format is anticipated to reduce overhead by about 5%. YMMV, of course. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] A proposal for SQLite version 3.0
Yes, things are very tight on all of our products over here as well! I would like to know what causes a bloated file. Thanks, Allan http://www.aspire.ws http://store.aspire.ws -Original Message- From: Roy Black [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 10:38 PM To: [EMAIL PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another way, about 60% to 75% of an SQLite database file is the actual data being stored and the other 40% to 25% is overhead. If you have an example where the overhead is significantly larger than this, I'd be interested in seeing it. The new version 3.0 file format is anticipated to reduce overhead by about 5%. YMMV, of course. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Simon Berthiaume wrote: >> Notice that text strings are always transferred as type "char*" even if the text representation is UTF-16. This might force users to explicitely type cast some calls to function to avoir warnings. I would prefer UNICODE neutral functions that can take either one of them depending on the setting of a compilation #define (UNICODE). Create a function that takes char * and another that takes wchar_t * them encourage the use of a #defined symbol that would switch depending on context (see example below). It would allow people to call the functions in either way they want. Example: int sqlite3_open8(const char*, sqlite3**, const char**); int sqlite3_open16(const wchar_t*, sqlite3**, const wchar_t**); #ifdef UNICODE #define sqlite3_open sqlite3_open16 #else #define sqlite3_open sqlite3_open8 #endif I'm told that wchar_t is 2 bytes on some systems and 4 bytes on others. Is it really acceptable to use wchar_t* as a UTF-16 string pointer? Note that internally, sqlite3 will cast all UTF-16 strings to be of type "unsigned char*". So the type in the declaration doesn't really matter. But it would be nice to avoid compiler warnings. So what datatype are most systems expecting to use for UTF-16 strings? Who can provide me with a list? Or even a few examples? -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
On Wed, 7 Apr 2004, D. Richard Hipp wrote: >A design proposal for SQLite version 3.0 can be found at: > > http://www.sqlite.org/prop2.html > >Feedback from the user community is strongly encouraged. >An executive summary of the proposed changes follows: > >* Support for UTF-16 > >I do not have much experience with UTF-16 and am >expecially interested in feedback on that area of >the design. > For better or for worse (I've not much experience myself) other systems use wchar to represent UTF-16 strings, so it might be worth adopting that convention. This may cause problems, though, as we'd have to check if wchar is defined, and typedef it ourselves if not. If you're going to be changing the function prefix to sqlite3_, then it might also be worth changing the header file to sqlite3.h as well, that way we can also provide a seperate sqlite.h which wraps the sqlite3 API in the old API. I'd prefer that than being able to use the two library versions at the same time. Is there much call for a binary to use two versions of the library at the same time? Surely the proper dump/restore as discussed a few weeks would be better for data compatibility? Cheers, Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Hello, I am using SQLite in a car navigation system which should work on PDAs as well. Thus speed and size is crucial for us. SQLite is superb in the speed category, but the size of its file is not so superb. I see you mentioned something about file size. My experience is that SQLite makes roughly about 3x bigger files than MS Access. How would this change in 3.0? Thanks for your excellent work, Jakub Adamek D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
As a developer of Delphi components for SQLite I would recommend a new function for both releases to investigate the fileversion. Perhaps it's already there. Of course you can open a database and wait for an exception to occur, but this is not a very clean way of doing things. Having this possibility it would mean that the single component set will be able to handle both sqlite versions, and call different routines and allocate different dll, depending on the version of the file. function GetSQLiteFileVersion(FileId : pChar) : cardinal; albert drent aducom software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
