Dariusz Pietrzak wrote:
>
> > * $Session & $Application stored in the database. In case
> > Apache::Session is not good enough, this would store
> > state in databases, and also enable things like Session
> > garbage collection & events like Session_OnEnd.
> This feature has my vote.
I think you win... better to add power to the hands of the
developers already working with Apache::ASP, than try
to entice VBScript users to the platform for now.
Database $Session & $Application support has been a
long requested feature.
> I could/would also like to work on this.
>
Depending on how much time I have free in the next
few weeks, I may take you up on this. I might
just knock it out myself though.
What I'm thinking is something similar to Apache::Session,
but slightly different. First of all, creation/updation/deletion
dates will be important and might find themselves as part
of the schema def for the state table, something like:
create table asp_state (
group_id varchar(12) NOT NULL,
state_id varchar(32) NOT NULL,
subkey varchar(200) NOT NULL,
deletion datetime NULL,
data text/long,
primary key(group_id, state_id, subkey)
)
This will allow for a similar mapping that already
exists for the directory/DBM based implementation.
The trick here is that while $Application and $Internal
(used internally for session management) will
have "subkeys" by default, $Session will not. Having
subkeys in the table will make is so that
$Application->{Key1}
$Application->{Key2)
would each invoke SQL to read in the data from
the DB like
select data from asp_state
where group_id = 'server'
and state_id = 'application'
and subkey = 'Key1'
allowing for larger objects to be stored in $Application
on a per key basis without having to read all the keys
like Apache::Session.
However $Session will be default likely behave like
an Apache::Session, with all the data being read
at the beginning of the request, and written out
at the end if anything is different. This data might
be stored in some default subkey like "DATA", with SQL
like:
select data from asp_state
where group_id = '12'
and state_id = '1234123123432141234'
and subkey = 'DATA'
This could only work though if SessionSerialize were
the default for these types of sessions. If someone
wanted to stored larger objects in session but didn't
want to necessarily access all of them during
the request, they might pick the deep subkey
$Application model.
I know that I need a deep subkey model. I don't
know that doing both models is a good idea for
code complexity. If someone wanted the flat model,
and it wasn't built into Apache::ASP, then they
could just use Apache::Session.
Also, where to get the database connection?
I imagine, that in global.asa, one would define:
# global.asa
sub Script_OnDBIConnect {
DBI->connect(...) or
My::DB->init(...)
}
This then could easily reuse your database connection
that your Application uses, especially where Apache::DBI
might be caching the connection.
Initial platform support would include Oracle & MySQL
as these are platforms with which I am familiar.
Hopefully the implementation will be flexible enough
to easily plug in additional databases.
Any feedback would be great.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
