:memory: and sessions with PHP

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

:memory: and sessions with PHP

CrazyChris
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


Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

Derrell Lipman
"CrazyChris" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

Firman Wandayandi
On 2/14/06, [hidden email]
<[hidden email]> wrote:

> "CrazyChris" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: :memory: and sessions with PHP

CrazyChris
In reply to this post by Derrell Lipman
We may be at crossed paths...  I'm wanting to save the :memory: database to
the session, not the other way round, so that when the 2nd page loads, the
:memory: database can be recreated and available as it was on the last page
load. The advantage is that after some time, the session is deleted
automatically by the server and the database goes with it, so short term,
high-intensity data can be stored and queried quickly in :memory: and the
add/edits remain through the entire user experience. An alternative is to
use a file based database per user, but this would require a tidy-up routine
to be manually coded, and makes the code less portable.

An alternative is to create the :memory: database and populate it from
session data each time, then save back to session on script close. Not as
swift or elegant, but if it's the only way then that may be that!



---

> 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

Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

Andrew Piskorski
On Wed, Feb 15, 2006 at 08:31:17AM +1300, CrazyChris wrote:
> We may be at crossed paths...  I'm wanting to save the :memory: database to
> the session, not the other way round, so that when the 2nd page loads, the
> :memory: database can be recreated and available as it was on the last page
> load.

What is a "session"?  I assume that's some special PHP or Apache
feature, but which?  How is a "session" implemented really?
Inter-process shared memory on Unix?  Process-wide memory in a
multi-threaded Apache 2.x build?  What?

Having an in-memory database (or in-memory anything) persist across
multiple page hits in a web server is certainly feasible, but for
anyone not using the exact same tools as you, you probably want to
give more background - basically, provide a mapping between
tool-specific jargon like "session", and more widely understood
programming terms.

> The advantage is that after some time, the session is deleted
> automatically by the server and the database goes with it, so short term,
> high-intensity data can be stored and queried quickly in :memory: and the
> add/edits remain through the entire user experience.

I don't see why that is any real advantage.  Periodically purging an
in-memory database of old values should be rather trivial.

> An alternative is to create the :memory: database and populate it from
> session data each time, then save back to session on script close.

That sounds like a bizarre hack.  (But then I don't know what your
sessions really are, nor do I really understand your application
requirements, so perhaps I am missing something.)

--
Andrew Piskorski <[hidden email]>
http://www.piskorski.com/
Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

Kervin L. Pierre
In reply to this post by CrazyChris
Hello,

I think the problem is that PHP uses a file-based
session serialization.  Therefore anything that
cannot be saved to a file and returned ( eg. you
can't do this with file handles, etc. ) cannot be
saved in session scope in PHP as it is implemented
by default.

There is the 'mm' extension ( search for reference
on http://us3.php.net/session ) that is suppose to
fix this, I've heard.  Also, there is word that
there will be memory based session in future
versions PHP engine by default.  I have never used
'mm'.

So, your problem is that you have no place to
put your SQLite handle after a script has
finished executing, so that the next instance
of the script can get it. PHP has no such scope
by default.

Best Regards,
Kervin


CrazyChris wrote:

> We may be at crossed paths...  I'm wanting to save the :memory: database to
> the session, not the other way round, so that when the 2nd page loads, the
> :memory: database can be recreated and available as it was on the last page
> load. The advantage is that after some time, the session is deleted
> automatically by the server and the database goes with it, so short term,
> high-intensity data can be stored and queried quickly in :memory: and the
> add/edits remain through the entire user experience. An alternative is to
> use a file based database per user, but this would require a tidy-up routine
> to be manually coded, and makes the code less portable.
>
> An alternative is to create the :memory: database and populate it from
> session data each time, then save back to session on script close. Not as
> swift or elegant, but if it's the only way then that may be that!
>
>
>
> ---
>
>
>>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
>
>

Reply | Threaded
Open this post in threaded view
|

RE: :memory: and sessions with PHP

Robert Foster-2
PHP Sessions are similar to session in ASP, ASP.Net, etc.  Objects within
the session are serialised into a stream and stored in the specified storage
medium.  By Default, PHP stores sessions in a file in the /tmp directory,
identified by a unique filename that is stored in a cookie on the browser if
it is supported, or encoded onto the URL if not.

You can also write custom session handlers, allowing you to store the
session anywhere else including a database.  There is some documentation on
the Zend.com site for using the Session api, but it's simply a matter of
writing some functions with specific names, and hooking them in via the php
configuration.

As far as storing a memory database, you would need to somehow grab a handle
to the memory location, keep the database alive between session hits, and
then re-attach to it.  Alternatively you could create some kind of database
serialisation method and serialise the database to the session.  It would,
however, be a lot more efficient to simply create a file-based database in
the first place and re-open it every time a page is called.

Hope this helps,


Robert Foster
General Manager
Mountain Visions P/L  http://mountainvisions.com.au

Serialised is spelt with an 's', not a 'z' (I'm Australian)

-----Original Message-----
From: Kervin L. Pierre [mailto:[hidden email]]
Sent: Wednesday, 15 February 2006 7:01 AM
To: [hidden email]
Subject: Re: [sqlite] :memory: and sessions with PHP

Hello,

I think the problem is that PHP uses a file-based session serialization.
Therefore anything that cannot be saved to a file and returned ( eg. you
can't do this with file handles, etc. ) cannot be saved in session scope in
PHP as it is implemented by default.

There is the 'mm' extension ( search for reference on
http://us3.php.net/session ) that is suppose to fix this, I've heard.  Also,
there is word that there will be memory based session in future versions PHP
engine by default.  I have never used 'mm'.

So, your problem is that you have no place to put your SQLite handle after a
script has finished executing, so that the next instance of the script can
get it. PHP has no such scope by default.

Best Regards,
Kervin


CrazyChris wrote:

> We may be at crossed paths...  I'm wanting to save the :memory:
> database to the session, not the other way round, so that when the 2nd
> page loads, the
> :memory: database can be recreated and available as it was on the last
> page load. The advantage is that after some time, the session is
> deleted automatically by the server and the database goes with it, so
> short term, high-intensity data can be stored and queried quickly in
> :memory: and the add/edits remain through the entire user experience.
> An alternative is to use a file based database per user, but this
> would require a tidy-up routine to be manually coded, and makes the code
less portable.

>
> An alternative is to create the :memory: database and populate it from
> session data each time, then save back to session on script close. Not
> as swift or elegant, but if it's the only way then that may be that!
>
>
>
> ---
>
>
>>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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

Jay Sprenkle
> You can also write custom session handlers, allowing you to store the
> session anywhere else including a database.  There is some documentation on
> the Zend.com site for using the Session api, but it's simply a matter of
> writing some functions with specific names, and hooking them in via the php
> configuration.
>
> <snip>
>
> Serialised is spelt with an 's', not a 'z' (I'm Australian)


So is zend.com australian for 'send.com'?  ;)



but seriously, if you run php as fastcgi could you keep your session information
in memory?
Reply | Threaded
Open this post in threaded view
|

RE: :memory: and sessions with PHP

Robert Foster-2
Comments below...


Robert Foster
General Manager
Mountain Visions P/L  http://mountainvisions.com.au

-----Original Message-----
From: Jay Sprenkle [mailto:[hidden email]]
Sent: Wednesday, 15 February 2006 8:38 AM
To: [hidden email]
Subject: Re: [sqlite] :memory: and sessions with PHP

>> You can also write custom session handlers, allowing you to store the
>> session anywhere else including a database.  There is some
>> documentation on the Zend.com site for using the Session api, but it's
>> simply a matter of writing some functions with specific names, and
>> hooking them in via the php configuration.
>>
>> <snip>
>>
>> Serialised is spelt with an 's', not a 'z' (I'm Australian)
>
>
>So is zend.com australian for 'send.com'?  ;)
Probably the other way around :P
>
>
>
>but seriously, if you run php as fastcgi could you keep your session
information in memory?
Probably, I haven't tried... (of course, if you stored the session info in a
:memory: database, and then somehow kept the database alive across the
session...)

Relevant articles for an off topic post...
http://www.zend.com/zend/spotlight/code-gallery-wade8.php
http://www.zend.com/manual/ref.session.php

Now we're way off the beaten track and calling for the search parties...

Reply | Threaded
Open this post in threaded view
|

Re: :memory: and sessions with PHP

D. Richard Hipp
In reply to this post by Robert Foster-2
"Robert Foster" <[hidden email]> wrote:

> PHP Sessions are similar to session in ASP, ASP.Net, etc.  Objects within
> the session are serialised into a stream and stored in the specified storage
> medium.  By Default, PHP stores sessions in a file in the /tmp directory,
> identified by a unique filename that is stored in a cookie on the browser if
> it is supported, or encoded onto the URL if not.
>
> You can also write custom session handlers, allowing you to store the
> session anywhere else including a database.  There is some documentation on
> the Zend.com site for using the Session api, but it's simply a matter of
> writing some functions with specific names, and hooking them in via the php
> configuration.
>
> As far as storing a memory database, you would need to somehow grab a handle
> to the memory location, keep the database alive between session hits, and
> then re-attach to it.  Alternatively you could create some kind of database
> serialisation method and serialise the database to the session.  It would,
> however, be a lot more efficient to simply create a file-based database in
> the first place and re-open it every time a page is called.
>

Based on your description above, I would recommend the following
for a session database:

  *  Create a file database with some unique name in /tmp
  *  Open the database for each hit, but immediately set
     PRAGMA synchronous=OFF;

With PRAMGA synchronous=OFF, all of your "disk I/O" is really
just going into your operating systems disk cache - very little if
any of it is actually going to disk.  So you get most of the speed
benefits of a :memory: database.  The reason you do not normally
set PRAGMA synchronous=OFF is because with synchronization off,
you run a very serious risk of database corruption following an
OS crash or power failure.  But for a session database, you don't
care.  If the OS crashes or the power fails, you've lost the
session anyway.
--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

To whom to inform on a bug?

Kirill-5
In reply to this post by Robert Foster-2
hello

select * from tResult where tex like '%ra%'
result = 0

select tex from tResult where id  = 3229
tex = "...Oracle..."

bag?

--
Kirill
Reply | Threaded
Open this post in threaded view
|

Re: To whom to inform on a bug?

D. Richard Hipp
Kirill <[hidden email]> wrote:
> hello
>
> select * from tResult where tex like '%ra%'
> result = 0
>
> select tex from tResult where id  = 3229
> tex = "...Oracle..."
>

http://www.sqlite.org/cvstrac/tktnew

Hints:  Unless you provide more information that you have
shown above, your ticket will likely be ignored.  The
following kinds of information will help us to isolate
and fix the problem:

   * What version of SQLite you are running.
   * What operating system you are using.
   * Did you build it yourself or used a precompiled
     binary.
   * What language bindings you are using.
   * The database schema.
   * The specific SQL statement that fails.
   * Can you reproduce the problem using the command-line
     shell or does it only appear in your program?
   * Include a reproducible script that demonstrates
     the problem.
   * If appropriate, attach a ZIP archive of your database
     file to the ticket.

--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re[2]: To whom to inform on a bug?

Kirill-5
version:
  3.3.4 or 3.x

System test:
  Win2003(NTFS)

Script:
  select * from tResult where tex like '%ra%'
  result = 0

  select tex from tResult where id  = 3229
  tex = "...Oracle..."

Soft on broblem:
  sqlite3explorer,
  and my soft

sample db:
  http://www.aidagw.com/files/dba.zip


dhc> http://www.sqlite.org/cvstrac/tktnew

dhc> Hints:  Unless you provide more information that you have
dhc> shown above, your ticket will likely be ignored.  The
dhc> following kinds of information will help us to isolate
dhc> and fix the problem:

dhc>    * What version of SQLite you are running.
dhc>    * What operating system you are using.
dhc>    * Did you build it yourself or used a precompiled
dhc>      binary.
dhc>    * What language bindings you are using.
dhc>    * The database schema.
dhc>    * The specific SQL statement that fails.
dhc>    * Can you reproduce the problem using the command-line
dhc>      shell or does it only appear in your program?
dhc>    * Include a reproducible script that demonstrates
dhc>      the problem.
dhc>    * If appropriate, attach a ZIP archive of your database
dhc>      file to the ticket.

dhc> --
dhc> D. Richard Hipp   <[hidden email]>







Reply | Threaded
Open this post in threaded view
|

Re: To whom to inform on a bug?

D. Richard Hipp
Kirill <[hidden email]> wrote:

> version:
>   3.3.4 or 3.x
>
> System test:
>   Win2003(NTFS)
>
> Script:
>   select * from tResult where tex like '%ra%'
>   result = 0
>
>   select tex from tResult where id  = 3229
>   tex = "...Oracle..."
>
> Soft on broblem:
>   sqlite3explorer,
>   and my soft
>
> sample db:
>   http://www.aidagw.com/files/dba.zip
>

Thank you for the excellent information.

Your query works correctly when run in the
sqlite3 shell.  Probably this is a bug in
sqlite3explorer.

--
D. Richard Hipp   <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re[2]: To whom to inform on a bug?

Kirill-5
sorry :(

>> version:
>>   3.3.4 or 3.x
>>
>> System test:
>>   Win2003(NTFS)
>>
>> Script:
>>   select * from tResult where tex like '%ra%'
>>   result = 0
>>
>>   select tex from tResult where id  = 3229
>>   tex = "...Oracle..."
>>
>> Soft on broblem:
>>   sqlite3explorer,
>>   and my soft
>>
>> sample db:
>>   http://www.aidagw.com/files/dba.zip
>>

dhc> Thank you for the excellent information.

dhc> Your query works correctly when run in the
dhc> sqlite3 shell.  Probably this is a bug in
dhc> sqlite3explorer.

dhc> --
dhc> D. Richard Hipp   <[hidden email]>





Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: To whom to inform on a bug?

Chris Schirlinger
In reply to this post by Kirill-5
I tried the data you mentioned in SQLite Explorer and the SQL
statemen worked correctlyt:

>   select * from tResult where tex like '%ra%'

returned the expected record perfectly

Here is the output of the command line test

SQLite version 3.3.3
Enter ".help" for instructions
sqlite> .schema
CREATE TABLE tResult (id INTEGER,tex STRING);
sqlite> select * from tResult;
3229|...Oracle...
sqlite> select * from tResult where tex like '%ra%';
3229|...Oracle...


> Script:
>   select * from tResult where tex like '%ra%'
>   result = 0
>
>   select tex from tResult where id  = 3229
>   tex = "...Oracle..."
>
> Soft on broblem:
>   sqlite3explorer,
>   and my soft



Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: To whom to inform on a bug?

Robert Simpson
> -----Original Message-----
> From: Chris Schirlinger [mailto:[hidden email]]
> Sent: Tuesday, February 14, 2006 8:45 PM
> To: [hidden email]
> Subject: Re: Re[2]: [sqlite] To whom to inform on a bug?
>
> I tried the data you mentioned in SQLite Explorer and the SQL
> statemen worked correctlyt:
>
> >   select * from tResult where tex like '%ra%'
>
> returned the expected record perfectly
>
> Here is the output of the command line test
>
> SQLite version 3.3.3
> Enter ".help" for instructions
> sqlite> .schema
> CREATE TABLE tResult (id INTEGER,tex STRING);
> sqlite> select * from tResult;
> 3229|...Oracle...
> sqlite> select * from tResult where tex like '%ra%';
> 3229|...Oracle...


Perhaps the original poster is using a non-English version of Windows?  Not
sure if that makes a difference in this case.

Robert


Reply | Threaded
Open this post in threaded view
|

libsql

Kirill-5
In reply to this post by Kirill-5
Somebody works with these components:

http://sourceforge.net/projects/libsql

What can tell good or bad?


Reply | Threaded
Open this post in threaded view
|

Mac OS

Kirill-5
Whether will be SqlLite in the future and under Mac OS if there will be that as soon?





Reply | Threaded
Open this post in threaded view
|

Re: Mac OS

Darren Duncan
At 11:32 AM +0600 2/15/06, Kirill wrote:
>Whether will be SqlLite in the future and under Mac OS if there will
>be that as soon?

SQLite runs under Mac OS X right now, and has for a long time.  A
version is even bundled with X.4 Tiger. -- Darren Duncan