On Fri, Aug 21, 2015 at 1:02 PM, sqlite-mail <sqlite-mail at dev.dadbiz.es> wrote:
> Thank you for your attention ! > > I'm pointing this here because postgresql do manage this case properly ! > ?And is significantly larger and harder to install. PostgreSQL is not "lite"! I know. I use it and love it. ? > > And I'm creating a tool to prototype database applications and I'm using > sqlite as the primary database, when we are prototyping things can change > drastically at any point and if we already have a lot of views/triggers > it's > a pain in the ass to fix it (postgresql does it fine). > ?Which is why I keep all my definitions in a file. I edit them there, then use the ".read" in sqlite3 to bring them all in. Granted this doesn't help if you have a lot of data in the data base. In that case, I don't rename. I create the new table and populate it with the data in the old table via a INSERT INTO ... SELECT ... ? > > Also that we got to this point would be nice if sqlite implemented a basic > SQL ANSI data dictioanry, I mean sqlite already provide most of the info > for a basic data dictionary but in a non compliant way "PRAGMAS", although > is > better than nothing we can not use that info on sql statements like > views/joins. > ?OK, implement one. This would be an _excellent_ "add on" product. Write a program which reads the data base schema. Using that internal schema, determine how to update all the dependencies. To implement, send all the required commands to the sqlite3 API. ? -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
