On 18-Jun-09, at 4:01 AM, Tomas Doran wrote:
Any session data at all? Can you be more specific - I'd guess that
this should only hit you if the length is small, or if your sessions
get large.
No, the sessions were tiny, more or less all they held was the id for
which project the user was working on. The field allocated was "text"
type, and it looks like MSSQL basically throws a truncation error for
"long" type, no matter how much data was actually in there. DBI
permits this. This was something of a surprise. If I'd declared the
type as a VARCHAR of some kind, I'd have got away with it.
Unfortunately, you can't get away from the need to make a separate
connection as easily.
Also, is there a different data type you can use without this
behavior? (One that at least fails rather than silently truncating
stuff would be good, for a start)..
Yes, a VARCHAR(4000) or so would probably do fine for my purposes.
Although my actual solution was C::P::Session::Store::Delegate with
some additional logic to delegate to my existing user data model,
which has a bunch of non-session stuff. This eventually worked well,
when I finally figured the requirement for this to support any
additional fields, and to keep user and session data separate. It even
seemed to handle the overlapping query issues. DBIC saved the day
(again!).
The way the statements are set up (in a batch) makes it hard to set
this for one statement independently, and supposedly it needs to be
set before a statement is prepared.
Why not just arrange for it to be set by all queries done by the
session handling? If you already have a dedicated DB connection for
session data, why not use it? :)
That would have worked fine, but DBIC handles all this directly, so
delegating to that solved all the issues. I guess my comments should
really be read as "in anyone is ever patching
C::P::Session::Store::DBI, here are a some things that could probably
be added." In its out of the box form, it would have needed an
override or two to work. As it is, C::P::Session::Store::Delegate is
working very smoothly, and running stable with MSSQL.
Cheers
t0m
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
