Re: [sqlite] sqlite3 struct etc
> It is not a smart technique to assume that you can access underlying > data structures and expect them to remain identically placed between > releases. What do you think, was my reason to ask, whether these structures are public and stable or not ... ;-) Micha --
Re: [sqlite] sqlite3 struct etc
Micha Bieber wrote: Thursday, May 18, 2006, 17:36:53, Jay Sprenkle wrote: Since you pass that in to begin with, why do you need the database to provide information you already have? Thats by design (tm), but it might be not the best one. For performance reasons I have splitted my project in a way, requiring 2 database files. The first one holding all sort of tricky information. This database is pretty small. The second one holds somewhat bulky amounts of data. Several millions of rows distributed in 200 tables. I have to care for everything I do with this db. So also deleting the poor thing is at times the best solution todo anything in time. Of course both tables are logically intertwined and I have all sorts of different requirements - open/creating/updating the one, but not the other, etc. Attaching the big one to the small table. At different times not only during creation. For this, it helps to link the file name of one of the databases as a special table entry into the other. To do so, it would be nice to have access to the file name at random times. Micha In that case make your DB context a structure which holds the pointer to the open db structure and the file or path name, plus any other attributes you may want to access similarly. It is not a smart technique to assume that you can access underlying data structures and expect them to remain identically placed between releases.
Re: [sqlite] sqlite3 struct etc
Maybe you are too C++ orientated. You have no need to touch any Sqlite structure, that is what the API does. Just use it. JS Micha Bieber wrote: @list Maybe I'm too C++ biased - but what is the state of the sqlite3 and similar - e.g. 'Db' - structures in sqlites C-Interface ? Is this considered 'public' and also stable or indicates the missing documentation (at least I've found nothing apart from the sources) not to use them in user code otherwise than as opaque pointer for the sqlite interface ? Micha
Re: [sqlite] sqlite3 struct etc
Micha Bieber <[EMAIL PROTECTED]> wrote: > @list > > Maybe I'm too C++ biased - but what is the state of the sqlite3 and > similar - e.g. 'Db' - structures in sqlites C-Interface ? Is this > considered 'public' and also stable or indicates the missing > documentation (at least I've found nothing apart from the sources) not to > use them in user code otherwise than as opaque pointer for the sqlite > interface ? > The sqlite3* and sqlite3_stmt* pointer are intended to be opaque. Their internal design is subject to drastic change from one point release to the next. If you search the history of the SQLite project you will find that both of these structure have undergone radical changes in the past. Additional radical changes are likely in the future. If you write code that depends on the internal layout of these structures, your code will very likely break in future releases of SQLite. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] sqlite3 struct etc
Thursday, May 18, 2006, 17:36:53, Jay Sprenkle wrote: > Since you pass that in to begin with, why do you need the database > to provide information you already have? Thats by design (tm), but it might be not the best one. For performance reasons I have splitted my project in a way, requiring 2 database files. The first one holding all sort of tricky information. This database is pretty small. The second one holds somewhat bulky amounts of data. Several millions of rows distributed in 200 tables. I have to care for everything I do with this db. So also deleting the poor thing is at times the best solution todo anything in time. Of course both tables are logically intertwined and I have all sorts of different requirements - open/creating/updating the one, but not the other, etc. Attaching the big one to the small table. At different times not only during creation. For this, it helps to link the file name of one of the databases as a special table entry into the other. To do so, it would be nice to have access to the file name at random times. Micha --
Re: [sqlite] sqlite3 struct etc
> but seriously, it's a black box that you don't need to pry open to use Sqlite. Something of course, was driving me in posting the question - it was programmers laziness, as usual :-) In this case, it was the databases filename, available from one of the mentioned structures. There are other ways to hold them, but perhaps it is is also a candidate for the public interface. Since you pass that in to begin with, why do you need the database to provide information you already have? It's been interesting reading the mailing list. There are all kinds of unique and interesting projects being done with sqlite. You just never know if someone is doing something really dfferent with it. I wasn't sure if your application was one of those.
Re: [sqlite] sqlite3 struct etc
Thursday, May 18, 2006, 17:09:12, Jay Sprenkle wrote: > but seriously, it's a black box that you don't need to pry open to use Sqlite. Something of course, was driving me in posting the question - it was programmers laziness, as usual :-) In this case, it was the databases filename, available from one of the mentioned structures. There are other ways to hold them, but perhaps it is is also a candidate for the public interface. Micha --
Re: [sqlite] sqlite3 struct etc
On 5/18/06, Micha Bieber <[EMAIL PROTECTED]> wrote: Maybe I'm too C++ biased - but what is the state of the sqlite3 and similar - e.g. 'Db' - structures in sqlites C-Interface ? Is this considered 'public' and also stable or indicates the missing documentation (at least I've found nothing apart from the sources) not to use them in user code otherwise than as opaque pointer for the sqlite interface ? Jay's law of application programming: "Thou shalt not mess with the internal structures of the application library, even if they are public. That way lies madness." ;) but seriously, it's a black box that you don't need to pry open to use Sqlite.
