Re: [sqlite] OK to drop support for legacy file formats?
On 9 Feb 2004, at 14:53, D. Richard Hipp wrote: Brass Tilde wrote: My understanding is that SQLite has had this auto-update feature since version 2.6.0. If I understand correctly, you should only have a problem if you are *now* using a version prior to that, and go from that version directly to 2.8.12 or later. If you've kept your version of the db engine current, or at least have upgraded to 2.6.0 or later, then all of your databases should now have their indices updated by now. Have I misinterpreted something? Your interpretation is correct. Dropping the auto-update feature would only impact people who jump directly from version 2.5.6 or earlier to version 2.8.13 or later, ignoring 19 months of changes and improvements in between. Yes, but I assume you're also suggesting that next time you change the DB format you won't add in auto-update. That might make things painful. Is my assumption wrong? Matt. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
Brass Tilde wrote: My understanding is that SQLite has had this auto-update feature since version 2.6.0. If I understand correctly, you should only have a problem if you are *now* using a version prior to that, and go from that version directly to 2.8.12 or later. If you've kept your version of the db engine current, or at least have upgraded to 2.6.0 or later, then all of your databases should now have their indices updated by now. Have I misinterpreted something? Your interpretation is correct. Dropping the auto-update feature would only impact people who jump directly from version 2.5.6 or earlier to version 2.8.13 or later, ignoring 19 months of changes and improvements in between. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> On 6 Feb 2004, at 14:05, D. Richard Hipp wrote: > > > If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > > to open an older database file (version 2.1.0 through 2.5.6) the > > library will automatically rebuild all the indices in the database > > in order to correct a design flaw in the older database files. > > > > I am proposing to drop support for this auto-update feature. > > I can see both sides of this. On the one hand I'm a *big* supporter of > keeping SQLite small, but on the other hand I have a project with > currently over 50,000 sqlite databases on a large (terabyte) > filesystem. Upgrading each one with a utility (and the associated > downtime) would be a bit of a nightmare. Upgrading them on a per-access > basis like the current implementation would do is a bit more agreeable > to me. My understanding is that SQLite has had this auto-update feature since version 2.6.0. If I understand correctly, you should only have a problem if you are *now* using a version prior to that, and go from that version directly to 2.8.12 or later. If you've kept your version of the db engine current, or at least have upgraded to 2.6.0 or later, then all of your databases should now have their indices updated by now. Have I misinterpreted something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
On 6 Feb 2004, at 14:05, D. Richard Hipp wrote: If you use a modern version of SQLite (version 2.6.0 through 2.8.11) to open an older database file (version 2.1.0 through 2.5.6) the library will automatically rebuild all the indices in the database in order to correct a design flaw in the older database files. I am proposing to drop support for this auto-update feature. Beginning with 2.8.12, if you attempt to open a database file built using version 2.5.6 or earlier, the open attempt will fail (with an appropriate error message). You will have to update the database file manually. Would this proposed change cause anyone unreasonable hardship? I can see both sides of this. On the one hand I'm a *big* supporter of keeping SQLite small, but on the other hand I have a project with currently over 50,000 sqlite databases on a large (terabyte) filesystem. Upgrading each one with a utility (and the associated downtime) would be a bit of a nightmare. Upgrading them on a per-access basis like the current implementation would do is a bit more agreeable to me. Tough choice. Matt. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
- Original Message - From: "Nate Bargmann" <[EMAIL PROTECTED]> > A plugin style of architecture seems much better than a bloated > all-in-one approach. Agreed, a plug-inn mechanism or lib-sqlite-bloated would do the job just as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
* Jonas Forsman / Axier.SE <[EMAIL PROTECTED]> [2004 Feb 07 07:16 -0600]: > My opinion is that the core code should be extremely > small and fast and complie to ansi sql as far as possible. > > To this, the interface where you can add functions should > be more of a public library where people needing a certain > algorithm , say crypto or compatibility for this or that version, > just should be a downloadable plugin. My thoughts exactly. I discovered sqlite a few months ago and am impressed by its adherence to the "do one thing and do it well" philosophy. Things like MD5, conversions between data stored by sqlite and mysql or postgresql are side issues and detract from the above stated philosophy. A public library seems to me to be the way to go. > Just have a project that checks the contributed name standard > of the provided functions so that it does not by accident can be > found two plugin-functions with the same name. > Ideally, someone is also reviewing the patches for qualtiy before they > are put in the public plugin-area. A plugin style of architecture seems much better than a bloated all-in-one approach. - Nate >> -- Wireless | Amateur Radio Station N0NB | Successfully Microsoft Internet | [EMAIL PROTECTED] | free since January 1998. Location | Bremen, Kansas USA EM19ov | "Debian, the choice of Amateur radio exams; ham radio; Linux info @ | a GNU generation!" http://www.qsl.net/n0nb/ | http://www.debian.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
On 7 Feb 2004 at 12:10, Rene wrote: > > How old is 2.5.6 version? > > july 7. 2002 > http://www.sqlite.org/cvstrac/timeline?d=3000&e=2004-Feb-07&c=0&px=&s=0&dm=1&dt=1&x=1&m=1 > > i'm just wondering what strategy will be if database format changes in the > future, do we depend on external utility then? I think the answer should be 'yes'. There are lots of ways you can move a DB from one engine to another, but if you have an 'orphaned' DB, then you're just out of luck, and we can't all have the luxury of storing a complete text-format data dump of our database around. I'm concerned about 'legacy' databases -- if/when the sysadmins update the SQLite package, all of my apps will die. But worse: some of my very infrequently used DBs [e.g., an archived log DB from past years] will become irretrievably dead. so I think, just as Word and Word Perfect and Excel and other such apps do, I really think that SQLite should have available 'helper' apps that'll be able to convert just about ANY old DB format to whatever-is- current. I agree, that the DB engine, itself, should *NOT* be larded up with all of that kind of stuff: keep it lean and mean. But *do* avoid orphaning our old data... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
hi, yes, user defined function / callback functionality is there. and of course, user defined functions are great! but i think sqlite should also (try to) compete with alternatives. for some platforms (scripting languages like php) udf may just be (too) slow. i don't mind nor care adding more of those functions, but i think at least 1 encryption function should be available, for an obvious reason: storing passwords in databases. quite often, there is no need to store the password itself, but you just want some verification. next to that, sqlite does not have any mechanism for restricting access, it depends on file privileges. so you have to think twice before storing passwords in plain text in a sqlite DB. what are arguments for this minimalistic approach? in this case not platform compatability, or code size. i can understand that we do not want to end up with 5Mb of executable code, but smallest possible footprint is not (my) major issue. - Original Message - From: "Michael Roth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 2:04 PM Subject: Re: [sqlite] OK to drop support for legacy file formats? > Rene wrote: > >>Why not remove the feature but create a seperate utility project that > >>converts any version of SQLITE DB to the latest version. > > > > > > i think it's better to let it in. why save a few bytes for removing such > > important functionality. by the way, same for md5, you should add support. > > You need MD5. The nextone needs SHA1. Another one needs CRC16. Some > folks may need a function to count hills in an given area. > > Sqlite is a database library and isn't an universal calculator. A > software package should do one thing and should it do well. A database > should store and retrieve data and shouldn't calculate crypto stuff. > > If you need a special function foo() use the extension api of sqlite. > > - > 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] OK to drop support for legacy file formats?
> If you need a special function foo() use the extension api of sqlite. This is perfectly correct! Few bytes are the footprint of a quick and small database. Thats is more or less the definition. Code that is rarely used and also, does not provide a core function in sqlite, should simply not be there. The discussion gets off the target because if you ask someone if support for this function or that thing is compiled in, there will always be stuff missing and the design goal for sqlite will start diverge from the "small footprint trademark". However, first of all, I am an administrator, and a user and mainly uses and implements sqlite in my applications so bare with me if am totally off track here. My opinion is that the core code should be extremely small and fast and complie to ansi sql as far as possible. To this, the interface where you can add functions should be more of a public library where people needing a certain algorithm , say crypto or compatibility for this or that version, just should be a downloadable plugin. Just have a project that checks the contributed name standard of the provided functions so that it does not by accident can be found two plugin-functions with the same name. Ideally, someone is also reviewing the patches for qualtiy before they are put in the public plugin-area. regards, Jonas Forsman - Original Message - From: "Michael Roth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 2:04 PM Subject: Re: [sqlite] OK to drop support for legacy file formats? > Rene wrote: > >>Why not remove the feature but create a seperate utility project that > >>converts any version of SQLITE DB to the latest version. > > > > > > i think it's better to let it in. why save a few bytes for removing such > > important functionality. by the way, same for md5, you should add support. > > You need MD5. The nextone needs SHA1. Another one needs CRC16. Some > folks may need a function to count hills in an given area. > > Sqlite is a database library and isn't an universal calculator. A > software package should do one thing and should it do well. A database > should store and retrieve data and shouldn't calculate crypto stuff. > > If you need a special function foo() use the extension api of sqlite. > > - > 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] OK to drop support for legacy file formats?
Rene wrote: Why not remove the feature but create a seperate utility project that converts any version of SQLITE DB to the latest version. i think it's better to let it in. why save a few bytes for removing such important functionality. by the way, same for md5, you should add support. You need MD5. The nextone needs SHA1. Another one needs CRC16. Some folks may need a function to count hills in an given area. Sqlite is a database library and isn't an universal calculator. A software package should do one thing and should it do well. A database should store and retrieve data and shouldn't calculate crypto stuff. If you need a special function foo() use the extension api of sqlite. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> How old is 2.5.6 version? july 7. 2002 http://www.sqlite.org/cvstrac/timeline?d=3000&e=2004-Feb-07&c=0&px=&s=0&dm=1&dt=1&x=1&m=1 i'm just wondering what strategy will be if database format changes in the future, do we depend on external utility then? i think from the users point of view, the key of a database is the data, not the engine. normally i would not have problems with it, it's just that sqlite is not comparable to other db environments, since it is embedded only. and that's why it should be as maintaince-free as possible imo. there may be environments where users are not able to run conversion tools at all (php & 3rd party hosting for example). same for people distributing applications that use sqlite. not all users are programmers or gurus, and why put extra work to them. i agree so far that in 2002 sqlite may have been not that populair as it is now. but the lifetime cycle of an application may well be longer than 1 1/2 year.. only point for stripping is made by eno, who sais it may be dangerous. richard, do you really bump in that much trouble leaving the code in? - Original Message - From: "Ondrej Krsko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 1:48 AM Subject: RE: [sqlite] OK to drop support for legacy file formats? > How old is 2.5.6 version? > > I agree with Greg. > > -Original Message- > From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] > Sent: Friday, February 06, 2004 11:18 PM > To: D. Richard Hipp; [EMAIL PROTECTED] > Subject: Re: [sqlite] OK to drop support for legacy file formats? > > Hello, > Why not remove the feature but create a seperate utility project that > converts any version of SQLITE DB to the latest version. > > In this way SQLite can be just what it is small and fast. There would be a > tool from the orginal source which you would know would work and simple to > use. > > The current version of SQLite would need to error when openning an older > formatted DB file. > > regards > Greg > > > > - > 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] OK to drop support for legacy file formats?
On Fri, 6 Feb 2004, D. Richard Hipp wrote: > Would this proposed change cause anyone unreasonable hardship? Given that I don't have any investment (code or data) in older SQLite versions, it will be no problem for me at all if you remove the auto-conversion feature. Moreover, I support the immediate removal of the feature from the SQLite core package. I believe that in order to keep a product nice and clean, all functionality regarding support for non-native/current data formats should be separated from the core program. They should take the form of a completely optional plug-in or separate utility. Better that the core not be cluttered. This said, you absolutely must keep functionality in the core that lets you detect whether the data file is in the current/native format or not, so nothing gets corrupted when you try to use a file. Raise an error if the file is not in the current format. However, if you can easily distinguish it, you should raise a different error for old versions of the SQLite file format vs attempts to open any other kind of file. Assuming that these errors are in a machine-readable format, I believe that someone who wants to maintain the old behaviour could create a wrapper for the current SQLite which also wraps a copy of the older SQLite. When asked to open a SQLite data file, it will try with the current core first, and if that raises an error citing an old file format, then the wrapper will try with the old core instead. The wrapper can also be used for a utility that migrates data to the new format; it reads the old file with the old core and writes the new file with the new core. A similar technique would also help in situations if you had to move data from a newer to an older version, for people stuck with old binaries that only know the older format. So in short, strip out the functionality. I assume there are copies somewhere of all your older releases which people can use if necessary. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] OK to drop support for legacy file formats?
How old is 2.5.6 version? I agree with Greg. -Original Message- From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] Sent: Friday, February 06, 2004 11:18 PM To: D. Richard Hipp; [EMAIL PROTECTED] Subject: Re: [sqlite] OK to drop support for legacy file formats? Hello, Why not remove the feature but create a seperate utility project that converts any version of SQLITE DB to the latest version. In this way SQLite can be just what it is small and fast. There would be a tool from the orginal source which you would know would work and simple to use. The current version of SQLite would need to error when openning an older formatted DB file. regards Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> Why not remove the feature but create a seperate utility project that > converts any version of SQLITE DB to the latest version. i think it's better to let it in. why save a few bytes for removing such important functionality. by the way, same for md5, you should add support. imho there is no reason at all to exclude functionality in default environment. rene - Original Message - From: "Allan Edwards" <[EMAIL PROTECTED]> To: "'Greg Obleshchuk'" <[EMAIL PROTECTED]>; "'D. Richard Hipp'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 12:41 AM Subject: RE: [sqlite] OK to drop support for legacy file formats? > Now there is experience talking. I agree with this view point. > > -Original Message- > From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] > Sent: Friday, February 06, 2004 4:18 PM > To: D. Richard Hipp; [EMAIL PROTECTED] > Subject: Re: [sqlite] OK to drop support for legacy file formats? > > Hello, > Why not remove the feature but create a seperate utility project that > converts any version of SQLITE DB to the latest version. > > In this way SQLite can be just what it is small and fast. There would be a > tool from the orginal source which you would know would work and simple to > use. > > The current version of SQLite would need to error when openning an older > formatted DB file. > > regards > Greg > > > > ----- Original Message ----- > From: "D. Richard Hipp" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 07, 2004 1:05 AM > Subject: [sqlite] OK to drop support for legacy file formats? > > > > If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > > to open an older database file (version 2.1.0 through 2.5.6) the > > library will automatically rebuild all the indices in the database > > in order to correct a design flaw in the older database files. > > > > I am proposing to drop support for this auto-update feature. > > Beginning with 2.8.12, if you attempt to open a database file > > built using version 2.5.6 or earlier, the open attempt will > > fail (with an appropriate error message). You will have to > > update the database file manually. > > > > Would this proposed change cause anyone unreasonable hardship? > > -- > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] OK to drop support for legacy file formats?
Now there is experience talking. I agree with this view point. -Original Message- From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] Sent: Friday, February 06, 2004 4:18 PM To: D. Richard Hipp; [EMAIL PROTECTED] Subject: Re: [sqlite] OK to drop support for legacy file formats? Hello, Why not remove the feature but create a seperate utility project that converts any version of SQLITE DB to the latest version. In this way SQLite can be just what it is small and fast. There would be a tool from the orginal source which you would know would work and simple to use. The current version of SQLite would need to error when openning an older formatted DB file. regards Greg - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 1:05 AM Subject: [sqlite] OK to drop support for legacy file formats? > If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > to open an older database file (version 2.1.0 through 2.5.6) the > library will automatically rebuild all the indices in the database > in order to correct a design flaw in the older database files. > > I am proposing to drop support for this auto-update feature. > Beginning with 2.8.12, if you attempt to open a database file > built using version 2.5.6 or earlier, the open attempt will > fail (with an appropriate error message). You will have to > update the database file manually. > > Would this proposed change cause anyone unreasonable hardship? > -- > 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] OK to drop support for legacy file formats?
Hello, Why not remove the feature but create a seperate utility project that converts any version of SQLITE DB to the latest version. In this way SQLite can be just what it is small and fast. There would be a tool from the orginal source which you would know would work and simple to use. The current version of SQLite would need to error when openning an older formatted DB file. regards Greg - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 1:05 AM Subject: [sqlite] OK to drop support for legacy file formats? > If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > to open an older database file (version 2.1.0 through 2.5.6) the > library will automatically rebuild all the indices in the database > in order to correct a design flaw in the older database files. > > I am proposing to drop support for this auto-update feature. > Beginning with 2.8.12, if you attempt to open a database file > built using version 2.5.6 or earlier, the open attempt will > fail (with an appropriate error message). You will have to > update the database file manually. > > Would this proposed change cause anyone unreasonable hardship? > -- > 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] OK to drop support for legacy file formats?
On Friday 06 February 2004 15:05, D. Richard Hipp wrote: > If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > to open an older database file (version 2.1.0 through 2.5.6) the > library will automatically rebuild all the indices in the database > in order to correct a design flaw in the older database files. > > I am proposing to drop support for this auto-update feature. > Beginning with 2.8.12, if you attempt to open a database file > built using version 2.5.6 or earlier, the open attempt will > fail (with an appropriate error message). You will have to > update the database file manually. > > Would this proposed change cause anyone unreasonable hardship? Surely not for me. And I think it's a Good Thing (TM) because this way somehow you force people to use a better version. There is no progress possible if you must care for legacy compatibility... regards, Yves -- Linux 2.4.24 #5 Mon Jan 5 19:38:06 CET 2004 i686 18:20:54 up 23 min, 1 user, load average: 0.12, 0.21, 0.16 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> If you use a modern version of SQLite (version 2.6.0 through 2.8.11) > > I am proposing to drop support for this auto-update feature. > Beginning with 2.8.12, if you attempt to open a database file If the opinion of someone who's just started using the product, and has no intention of using the older versions of which you speak, I shan't miss the feature either. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
Hi, I have not been an active contributer and I am only using it in an embedded project - not all that serious about time lines, however I have been bumping into conflicts about formats. I would definitely not miss it. It may add stability to the remainder and allow some additional growth. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> Would this proposed change cause anyone unreasonable hardship? I think it is a dangerous feature anyway, cause it can break older versions of some app if someone is using a newer version against an old database, resulting in a DB which can be opened any longer by the old app. Therefore, I wont miss it :) /eno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
Alle 15:05, venerdì 6 febbraio 2004, D. Richard Hipp ha scritto: > I am proposing to drop support for this auto-update feature. What about dropping this feature as part of sqlite and make it available as an external utility? (if one doesn't exist yet...) (I'm not using any old-style db, though, so opinions from people more affected are probably more important) -- Cesare D'Amico - boss (@t) cesaredamico (dot) com http://www.cesaredamico.com~ http://www.phpday.it The best way to accelerate a Windows machine is at 9.81 m/s^2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] OK to drop support for legacy file formats?
If you use a modern version of SQLite (version 2.6.0 through 2.8.11) to open an older database file (version 2.1.0 through 2.5.6) the library will automatically rebuild all the indices in the database in order to correct a design flaw in the older database files. I am proposing to drop support for this auto-update feature. Beginning with 2.8.12, if you attempt to open a database file built using version 2.5.6 or earlier, the open attempt will fail (with an appropriate error message). You will have to update the database file manually. Would this proposed change cause anyone unreasonable hardship? -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
