Re: [sqlite] SQLite as a Windows kernel tool
This has been the whole point of my emails -- I am not sufficiently familiar with the actual code details for me to make that determination. There are no comments to indicate whether the implicit cast is 'safe' or not. I know that some casts are a simple fact of life, especially in UN!X based code, where the runtime or system API returns character data in an integer, but the conversion of a 64-bit to an 32-bit value is a different case. If I could have determined the context to a reasonable degree of certainty, it would be one thing, but not being able to determine the actual intent raises some concerns. -ken On 29-Oct-05, at 12:56 PM, [EMAIL PROTECTED] wrote: Ken & Deb Allen <[EMAIL PROTECTED]> wrote: vdbeapi.c e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data What about these three warnings do you think is a concern? Have you actually looked at the code in question to see if the possibility of data loss is real and unintentional? What makes you think that these warnings are not just a case of the compiler blowing smoke? -- D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] OCaml binding for SQLite 3
Is it true that there isn't yet a binding to SQLite versoin 3 from Objective Caml? (I only found one for version 2.)
[sqlite] Re: Are DELETE TRIGGERS recursive or not?
Ralf Junker <[EMAIL PROTECTED]> wrote: I was looking for recursive delete triggers because the information I need to store in a single table is hierarchical in a sense that a record can refer to another record in the same table (like when storing a tree structure). With recursive delete triggers, a single delete would automatically delete all children AND GRANDCHILDREN of that tree's node. Deleting children with triggers is possible without recursion, but you need recursive delete triggers to delete the grandchildren also. Well, you don't strictly _need_ recursive triggers (as in, can't implement the same functionality without them), they are just more convenient. You can always write create trigger del_parents delete on parents begin delete from grandchildren where parentId in (select id from children where parentId = old.id); delete from children where parentId = old.id; end; create trigger del_children delete on children begin delete from grandchildren where parentId = old.id; end; Igor Tandetnik
RE: [sqlite] Are DELETE TRIGGERS recursive or not?
Hello Allan, Mark, I am not sure, but I don't think recursive delete triggers apply to your web-page example. I was looking for recursive delete triggers because the information I need to store in a single table is hierarchical in a sense that a record can refer to another record in the same table (like when storing a tree structure). With recursive delete triggers, a single delete would automatically delete all children AND GRANDCHILDREN of that tree's node. Deleting children with triggers is possible without recursion, but you need recursive delete triggers to delete the grandchildren also. I don't know if recursive delete triggers will improve performance, but they will certainly make it easier to maintain referential integrity for hierarchical, tree-like data. Regards, Ralf >Have you had a look at the following web-page:- > >http://www.justatheory.com/computers/databases/sqlite > >This is a way of enforcing referential integrity in SQlite with triggers >although evidently not with recursive triggers. >We have implemented this in our system. Would you mind explaining to me the >benefit of recursive triggers for this purpose? I ask as we are trying hard to >optimise the performance of our deletes, do you think using recursive triggers >(when implemented) will be more efficient at cascading deletes?
Re: [sqlite] SQLite as a Windows kernel tool
Ken & Deb Allen wrote: I had a quick look at some of the code, but I am not certain whether all, or even most, of these warnings can be safely ignored or not. I tried modifying the code to add explicit casts to eliminate all of the warnings, which worked, but I do not know whether or not the resulting code contains runtime errors or not (specifically as a result of data loss at runtime or improper comparison logic). You might want to look at ticket 1255 (http://www.sqlite.org/cvstrac/tktview?tn=1255,2).
Re: [sqlite] SQLite 3.2.5 and Mac OSX network folders
Thanks! That helps tremendously. As regards merging the changes, I've been in touch with drh over this and I understand he is already looking into this patch. So in the interest of not duplicating effort, I'm not going to make any attempt to submit a merge of these changes back into the most recent core code. Instead I plan to review and test the 3.1.3 based changes in my own project and if they past muster, I'll use that version. Otherwise I'll wait for an official core release that incorporates these or similar changes. Right now based on my limited testing I have some concerns over the performance of the locking. The implementation may well not be as optimal as it can be or possibly it is optimal but my code isn't optimised for network access. I don't know yet. - Steve On Oct 28, 2005, at 10:13pm, Aaron Burghardt wrote: The Makefile has this line: include $(MAKEFILEPATH)/CoreOS/ReleaseControl/GNUSource.make so you will need the Darwin project CoreOSMakefiles-30. Working backwards, GNUSource.make includes Common.make, which defines OBJROOT to be /tmp/$(ProjectName)/Build. With this, I found the built products in: /tmp/SQLite3/Build/.libs/ The makefiles appear to be from a Project Builder makefile-based project (does Xcode still support these?). Any, I was able to build it outside of Xcode and it may work to create a project if you want. (I didn't actually install the built product, so there may be issues with that step.) Here's another suggestion for you. Obviously you are going to be interested in merging Apple's changes in with the latest SQLite source. Subversion (and probably other SCMs) has some ability to track a branch relative to a vendor distribution (i.e., the standard SQLite distribution), which would help combine Apple's changes and the changes from 3.1.3 to 3.2.5. I've never used that feature of Subversion, so I can't offer much more at the moment. Keep us posted, I'm curious to know how this goes for you. Aaron On Oct 28, 2005, at 11:36 AM, Steve Palmer wrote: Has anybody tried building that though? If you download the files from http://www.sqlite.org/cvstrac/tktview?tn=1240 and run make from the root of the expanded folder then it will go through the process of configuring and building, but I can't find the output files anywhere. A search under the folder shows nothing seems to have been created. Interestingly, if you build from the SQLite3 folder, it will generate the object files and place the libraries in a hidden .libs folder but those all omit the new locking mechanism and hence the final results don't work for me. Unfortunately I can't quite figure out what is different. Any ideas? - Steve On Oct 27, 2005, at 6:09am, Aaron Burghardt wrote: You can take a look at what Apple has done for OS X here: http://www.opensource.apple.com/darwinsource/10.4/SQLite-28/ Don't be mislead by the project name--it is SQLite 3. I haven't studied it closely, but it should allow you to build exactly what Apple shipped. The Makefile has references to locking callbacks, so this might be relevant: # add -DSQLITE_DEBUG=1 to enable lock tracing and other debugging features # you also need to set sqlite3_os_trace to 1 in SQLite3/src/ os_common.h Extra_CC_Flags += -DASSERT_VIA_CALLBACK=1 - DENABLE_LOCKING_CALLBACKS=1 HTH, Aaron On Oct 25, 2005, at 12:45 PM, Steve Palmer wrote: What are those reasons and is there any expectation that they can be made available as patches for folks who build SQLite privately? I cannot use the libsqlite3.dylib that comes with Mac OSX 10.4 since my application needs to run on 10.3.9 too and there is no equivalent static version that I can find. - Steve On Oct 25, 2005, at 4:57am, [EMAIL PROTECTED] wrote: Steve Palmer <[EMAIL PROTECTED]> wrote: I'm currently investigating a problem with my application, SQLite 3.2.5 and a database located on a Mac OSX Server network share that does not seem to repro with the SQLite 3.1.3 that ships with Mac OSX 4.1. Specifically if I place a SQLite database file on a folder on a remote network share and attempt to access it using the sqlite3 utility, I get different results. Apple added special hacks to their release of SQLite 3.1.3 that allow it to work on remote filesystems with broken file locking. For various reasons, those hacks have not been incorporated into the SQLite core, yet. -- D. Richard Hipp <[EMAIL PROTECTED]>
