Re: [sqlite] Field drop work around

I just noticed that this is a FAQ: Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:41:55 +, Black, Michael (IS) wrote: > Since SQLite is type agnostic Actually no, it's not. The optimizer usually does much better job if the types are declared (I've seen many cases where it failed to use index when some column was untyped). Plus there are unique con

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:03:52PM +0100, Jack Hughes scratched on the wall: > Hello all, > > Is there a workaround for the lack of support for dropping fields? While this doesn't solve your immediate problem, I'm wondering if it might be possible to add code that simple marks a column invali

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:03:52 +0100, Jack Hughes wrote: > Any ideas how I can remove unused fields from the database would be > appreciated. I'd consider creating the new database from scratch and importing the data from the old one (by attaching it and doing insert ... select). That way you'd

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:41:55PM +, Black, Michael (IS) scratched on the wall: > Since SQLite is type agnostic why don't you use generic field names? Table definitions consist of a lot more than just column names and types. Defining keys and other constraints are an integral part of

Re: [sqlite] Field drop work around

On 02/08/2011, at 9:03 PM, Jack Hughes wrote: > Is there a workaround for the lack of support for dropping fields? As others have said, you can create a new table and insert data from the old to new table. Remember to also recreate any needed triggers and indexes. For example, I get my SQLite m

Re: [sqlite] Field drop work around

I don't think NHibernate would allow me do do that... even if it did it would be difficult to understand. Things are hard enough to understand when I name the fields as per their intention never mind when there would be a level of indirection above it. >Since SQLite is type agnostic why don't

Re: [sqlite] Field drop work around

Since SQLite is type agnostic why don't you use generic field names? Just name your fields 0-NN and keep a set of defines for field names. Then you just use #define to name the fields. create table mytable (field1,field2,field3,field4); #define NAME "field1" #define ADDR "field2" #def

Re: [sqlite] Field drop work around

On Tue, Aug 2, 2011 at 1:13 PM, Simon Slavin wrote: > copy your data across using INSERT INTO myTable SELECT a,b,c,d FROM > myOldTable > DROP the old TABLE > or, similarly: CREATE TABLE myTable AS SELECT ... FROM myOldTable; Though there might be subtle differences between the two which i'm not

Re: [sqlite] Field drop work around

Thank you for your response Simon + Teg. The absence of the full ALTER table support turns something that would have been as simple as writing "Delete.Column("ColumnName").FromTable("TableName");" in c# using the fluent migrator project into something that is far from simple and probably quite

Re: [sqlite] Field drop work around

Hello Jack, I just migrate the tables forward. Generate a new one in my program and do a bulk insert from the old to the new, then drop the old one. At other times, I've just re-purposed the unused field. C Tuesday, August 2, 2011, 7:03:52 AM, you wrote: JH> Hello all, JH> Is there a workarou

Re: [sqlite] Field drop work around

On 2 Aug 2011, at 12:03pm, Jack Hughes wrote: > Is there a workaround for the lack of support for dropping fields? I have an > application and need to evolve the database schema as features are added and > removed. Leaving fields sitting inside the database that are no longer used > will lead