Re: [sqlite] :memory: and sessions with PHP
On 2/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "CrazyChris" <[EMAIL PROTECTED]> writes: > > > Hi there, > > > > I have a need to create a :memory: sqlite database, but save it into the > > user session (PHP) but can't see a way to access the data to save. Looking > > for a sqlite version of serialize() I guess. > > > > Has anyone managed to do this? Is it even possible? > > > > Wanting to be able to maintain a large chunk of data across a users session > > on a website, and the array's are getting tedious to manage and search > > through! > > The PHP session information has to be persistent, so it's not going to be easy > to use a :memory: database. There is lots of information about how to save > session information to a database, though, on the PHP web site. I haven't > looked at it in a couple of years, but I'd guess that you'll get some good > pointers if you look at the documentation for session_set_save_handler(). > > Also, IIRC, PHP provides functions to do serialization. You won't need them > if you go the session_set_save_handler() route, but if you want to serialize > data yourself, those functions should be available. > > Derrell > I think Derrel is right. If you use a :memory: database, maybe you succeed on first page, but I guarrante your session will be destroyed on the other page, why? cause you create a brand new :memory: database. In order if you want to use sqlite session as save handler you can use it on php5, or you can create your own session rules. Take a look a php session documentation for it. -- Firman Wandayandi Never Dreamt Before: http://firman.dotgeek.org/ Wishlist: http://www.amazon.com/gp/registry/1AAN8NZBHW2W9
Re: [sqlite] :memory: and sessions with PHP
"CrazyChris" <[EMAIL PROTECTED]> writes: > Hi there, > > I have a need to create a :memory: sqlite database, but save it into the > user session (PHP) but can't see a way to access the data to save. Looking > for a sqlite version of serialize() I guess. > > Has anyone managed to do this? Is it even possible? > > Wanting to be able to maintain a large chunk of data across a users session > on a website, and the array's are getting tedious to manage and search > through! The PHP session information has to be persistent, so it's not going to be easy to use a :memory: database. There is lots of information about how to save session information to a database, though, on the PHP web site. I haven't looked at it in a couple of years, but I'd guess that you'll get some good pointers if you look at the documentation for session_set_save_handler(). Also, IIRC, PHP provides functions to do serialization. You won't need them if you go the session_set_save_handler() route, but if you want to serialize data yourself, those functions should be available. Derrell
[sqlite] :memory: and sessions with PHP
Hi there, I have a need to create a :memory: sqlite database, but save it into the user session (PHP) but can't see a way to access the data to save. Looking for a sqlite version of serialize() I guess. Has anyone managed to do this? Is it even possible? Wanting to be able to maintain a large chunk of data across a users session on a website, and the array's are getting tedious to manage and search through! Thanks
[sqlite] Re: Database Disk Full
At 04:47 AM 2/13/2006, John Stanton wrote: >Sigh... what is wrong with a message "disk full" when the disk space is >exhausted? Why is simple and to the point a problem? The "disk full" error is actually "write failed". Disk full may be the expected reason for a write to fail, but there are many others, not all even documented. Under most circumstances, you'll look at the disk space situation and decide "oh sure"; but what if your reaction is "huh?" and all the information you have is "disk full". For example, some operating systems support disk quotas, and a write will fail when you exceed the quota. In that case, if you're lucky, the error code might mean "quota exceeded". If all you got from sqlite is a generic disk full message, not based on the actual error code, you're still clueless. -- I'm not saying sqlite should to try to diagnose every possible failure, but when the unexpected inevitably happens, sqlite should make as much information as possible available to the host application. It's all part of building reliable and debuggable applications.
RE: [sqlite] Linux fcntl() threaded locking problem
> SQLite tests for the linux thread-locking bug at run-time using > the routine testThreadLockingBehavior() in os_unix.c. You can > use that code. Excellent. Thanks for the quick response. I'll have a look at the code and see how it fares. Dave
Re: [sqlite] extensible indexing
Martin Pfeifle wrote: Dear all, is it somehow possible to add an own index-structure, e.g. M-tree, R-tree, Quadtree...to SQLite? Has anyone ever done that? Best Martin ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de Hello Martin, Apparently nobody, I'm also very interested in R-Tree, I do build and use a Quadtree, but in memory. I also load gis data from sqlite, but without index. Does somebody knows how to complete the process ? (loading gis data with spatial index). I have read somewhere that a quadtree index can be encoded in an integer key, that would be enough for me. Does somebody has a pointer ? Best wishes -- Noël Frankinet Gistek Software SA http://www.gistek.net
Re: [sqlite] Linux fcntl() threaded locking problem
David Fiddes <[EMAIL PROTECTED]> wrote: > > Is there any test software or way of testing a particular Linux distribution > or C library installation to see if it suffers from the fcntl() locking > problem. > SQLite tests for the linux thread-locking bug at run-time using the routine testThreadLockingBehavior() in os_unix.c. You can use that code. -- D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] Linux fcntl() threaded locking problem
Hi, Is there any test software or way of testing a particular Linux distribution or C library installation to see if it suffers from the fcntl() locking problem. I would really like to use the new thread pooling capability in 3.3.x but am obviously wary of doing so if I'm not 100% confident in the platform. My software currently only targets Fedora Core 4 (for debug) and uclibc 0.9.28. I guess have quite a large potential variablility with one using NPTL and the other using LinuxThreads. Dave
RE: [sqlite] Re: Database Disk Full
Exactly, as per my original mail, there was no shortage of disk space on the drive in question, on the drive containing the temporary files, and the database file was 100kb. So SQLITE_FULL was misleading in this case. I will post further information about the exact cause when I have tracked it down. Regards, Steve -Original Message- From: Michael Knigge [mailto:[EMAIL PROTECTED] Sent: 13 February 2006 13:34 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Re: Database Disk Full > Sigh... what is wrong with a message "disk full" when the disk space > is exhausted? Why is simple and to the point a problem? The point is, that this error is returned everytime a write to the disk failed - even if (for example) the write failed because of a network error (NFS-Server is restarted for example). I remember that I've got a "disk full" message from MS-Word last year when I tried to print to a PDF-Printer (free space on my disk: 14 GB). Bye, Michael > > Drew, Stephen wrote: > >> John, >> >> Thanks for the reply. >> >> I disagree - my error message informs my users (who are technonerds) >> that the disk or db file is full, when neither of these is the case. >> >> Surely you can see that even a different constant error message in this >> context would be preferable? SQLITE_WRITE_FAILED or something? >> >> As I say, I'm just altering the standard error text at the moment, >> because it is misleading. >> >> Steve >> >> -Original Message- >> From: John Stanton [mailto:[EMAIL PROTECTED] Sent: 11 February 2006 >> 09:58 >> To: sqlite-users@sqlite.org >> Subject: Re: [sqlite] Re: Database Disk Full >> >> The first message informs all users of the problem. The one you propose >> might satisfy a technonerd, but confuse the more casual user. There is >> however a case for writing such a detailed message to syslog or similar >> system log. >> >> Dave Dyer wrote: >> It is a reasonable assumption to make that the only thing which can >> >> >> have changed since the last write is the disk becoming full. A disk >> cable falling off, head crash or mechanical disk failure is not only >> unlikely but would crash the entire machine and make error detection and >> recovery unlikely so testing for it is futile. >> >>> >>> It is reasonable for a program like sqlite to operate on the >>> assumption that other hardware and software perform as intended, and >>> not attempt heroic error recovery. >>> >>> On the other hand, sqlite operates in the real world, and wierd shit >>> happens out there. When something goes wrong, every bit of >>> information that is available should BE available to those trying to >>> clean up the mess. >>> >>> There is a huge difference, coming in in the morning after an expected >> >> >> >>> overnight run, finding it failed, and having the message >>> >>> database full >>> >>> verses having the message >>> >>> 09-feb-2006 03:13:12 database write failed, windows error code 14 for >> >> >> >>> f:\temp\vacuumtemp.txt, current file size = 10200K >>> >>> >> >> >> >> > > -- Mit freundlichen Grüßen Michael Knigge S.E.T. Software GmbH Lister Str. 15 30163 Hannover Tel.: +49 511 / 3 97 80 -23 Fax: +49 511 / 3 97 80 -66 eMail: [EMAIL PROTECTED]
Re: [sqlite] Re: Database Disk Full
Sigh... what is wrong with a message "disk full" when the disk space is exhausted? Why is simple and to the point a problem? The point is, that this error is returned everytime a write to the disk failed - even if (for example) the write failed because of a network error (NFS-Server is restarted for example). I remember that I've got a "disk full" message from MS-Word last year when I tried to print to a PDF-Printer (free space on my disk: 14 GB). Bye, Michael Drew, Stephen wrote: John, Thanks for the reply. I disagree - my error message informs my users (who are technonerds) that the disk or db file is full, when neither of these is the case. Surely you can see that even a different constant error message in this context would be preferable? SQLITE_WRITE_FAILED or something? As I say, I'm just altering the standard error text at the moment, because it is misleading. Steve -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: 11 February 2006 09:58 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Re: Database Disk Full The first message informs all users of the problem. The one you propose might satisfy a technonerd, but confuse the more casual user. There is however a case for writing such a detailed message to syslog or similar system log. Dave Dyer wrote: It is a reasonable assumption to make that the only thing which can have changed since the last write is the disk becoming full. A disk cable falling off, head crash or mechanical disk failure is not only unlikely but would crash the entire machine and make error detection and recovery unlikely so testing for it is futile. It is reasonable for a program like sqlite to operate on the assumption that other hardware and software perform as intended, and not attempt heroic error recovery. On the other hand, sqlite operates in the real world, and wierd shit happens out there. When something goes wrong, every bit of information that is available should BE available to those trying to clean up the mess. There is a huge difference, coming in in the morning after an expected overnight run, finding it failed, and having the message database full verses having the message 09-feb-2006 03:13:12 database write failed, windows error code 14 for f:\temp\vacuumtemp.txt, current file size = 10200K -- Mit freundlichen Grüßen Michael Knigge S.E.T. Software GmbH Lister Str. 15 30163 Hannover Tel.: +49 511 / 3 97 80 -23 Fax: +49 511 / 3 97 80 -66 eMail: [EMAIL PROTECTED]
Re: [sqlite] Re: Database Disk Full
Sigh... what is wrong with a message "disk full" when the disk space is exhausted? Why is simple and to the point a problem? Drew, Stephen wrote: John, Thanks for the reply. I disagree - my error message informs my users (who are technonerds) that the disk or db file is full, when neither of these is the case. Surely you can see that even a different constant error message in this context would be preferable? SQLITE_WRITE_FAILED or something? As I say, I'm just altering the standard error text at the moment, because it is misleading. Steve -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: 11 February 2006 09:58 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Re: Database Disk Full The first message informs all users of the problem. The one you propose might satisfy a technonerd, but confuse the more casual user. There is however a case for writing such a detailed message to syslog or similar system log. Dave Dyer wrote: It is a reasonable assumption to make that the only thing which can have changed since the last write is the disk becoming full. A disk cable falling off, head crash or mechanical disk failure is not only unlikely but would crash the entire machine and make error detection and recovery unlikely so testing for it is futile. It is reasonable for a program like sqlite to operate on the assumption that other hardware and software perform as intended, and not attempt heroic error recovery. On the other hand, sqlite operates in the real world, and wierd shit happens out there. When something goes wrong, every bit of information that is available should BE available to those trying to clean up the mess. There is a huge difference, coming in in the morning after an expected overnight run, finding it failed, and having the message database full verses having the message 09-feb-2006 03:13:12 database write failed, windows error code 14 for f:\temp\vacuumtemp.txt, current file size = 10200K
RE: [sqlite] Re: Database Disk Full
John, Thanks for the reply. I disagree - my error message informs my users (who are technonerds) that the disk or db file is full, when neither of these is the case. Surely you can see that even a different constant error message in this context would be preferable? SQLITE_WRITE_FAILED or something? As I say, I'm just altering the standard error text at the moment, because it is misleading. Steve -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: 11 February 2006 09:58 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Re: Database Disk Full The first message informs all users of the problem. The one you propose might satisfy a technonerd, but confuse the more casual user. There is however a case for writing such a detailed message to syslog or similar system log. Dave Dyer wrote: >>It is a reasonable assumption to make that the only thing which can have changed since the last write is the disk becoming full. A disk cable falling off, head crash or mechanical disk failure is not only unlikely but would crash the entire machine and make error detection and recovery unlikely so testing for it is futile. > > > It is reasonable for a program like sqlite to operate on the > assumption that other hardware and software perform as intended, and > not attempt heroic error recovery. > > On the other hand, sqlite operates in the real world, and wierd shit > happens out there. When something goes wrong, every bit of > information that is available should BE available to those trying to > clean up the mess. > > There is a huge difference, coming in in the morning after an expected > overnight run, finding it failed, and having the message > > database full > > verses having the message > > 09-feb-2006 03:13:12 database write failed, windows error code 14 for > f:\temp\vacuumtemp.txt, current file size = 10200K > >
[sqlite] extensible indexing
Dear all, is it somehow possible to add an own index-structure, e.g. M-tree, R-tree, Quadtree...to SQLite? Has anyone ever done that? Best Martin ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
