I am writing a tool to develop a database. Its basically a simple db browser and text editor. You can dump the whole database, edit it and restore it from text files. I thought it is a nice idea to have a "testing mode" where you load everything into a memory db (this is much faster). Therefore I would like to run genfkey.
btw: I am very happy with sqlite and I don't mind at all that fk constraints are not enforced (I am sure drh has good reasons why it's like that). Of course .genfkey is a great help. :-) Kees Nuyt schrieb: > On Mon, 20 Jul 2009 08:34:52 -0500, "Jay A. Kreibich" > <j...@kreibi.ch> wrote: > >> On Mon, Jul 20, 2009 at 12:41:59PM +0200, Jan scratched on the wall: >>> thank you roger. >>> >>> Seems it's not an easy task. Guess I should go through some c tutorials. >>> Would be really nice to have this included in sqlite itself. >> >> If someone is going to take the time to refactor the genfkey code >> into a stand-alone piece of code, I would like to suggest it is made >> into it a loadable module, so that it can be used pretty much anywhere. >> >> Also, if the code is written carefully, it is possible to use the same >> code to compile a module (.dll, .so, .dylib, etc.) or to compile >> directly into an SQLite build with very minimal changes (e.g. using >> #defines). That would be provide the most flexibility to the most >> people. >> >> -j > > Think Lite. > > After a dynamic development phase, most databases have a > static schema. At-run-time schema changes are usually a > result of bad design. Run-time schema changes on referential > constraints are very unlikely. > > Assuming the schema is static, there is no need to run > .genfkey very time. > > I would develop the schema in an on-disk db, open it with > the command line tool, run .genfkey to create the > referential triggers, dump the schema with .schema and use > that for priming every instance of that in-memory database. > > drh told us implementing real referential constraints in > SQLite is difficult. I think we'll have to do with triggers > for quite some time, which IMHO is no problem for a Lite > product. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
