>> Too many SQLite3 apps assume a rowid. But I agree that not having a rowid >> unless one is defined is the >> correct thing to do.
Darn right they do. I'm relatively new to SQLite, but from what I've seen all across the web, good use of the convenient rowed field is considered a best practice. I'm surprised it's being removed. >> I think AUTOINCREMENT should imply that the column values a) must be >> INTEGER, b) tracking the max value >> seen so far. (b) is tricky because it's tempting to not require an index on >> that column unless it's constrained to >> be unique (implied for a primary key), but then, if there is no index then >> ensuring that an autoincrement value >> is not used requires a leap of faith -- but again, if not declared unique >> then I think it's fair to assume that it isn't >> required to be unique. Why not just keep the maximum value stored in the metadata for the column? >> It's also possibly a good idea to just not have autoincrement. Let the >> application implement it, no? After all, it >> can, including via triggers. Gah! Remove functionality? That also forces the application to maintain the maximum seen, requiring an index or a secondary table. You're just pushing the problem onto the user and I don't think that's the place for it. Marc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
