On Wed, Nov 14, 2012 at 3:09 PM, Francisco Obispo <fobi...@isc.org> wrote:

> Did you use the dbicdump script (or myapp_create.pl model) command to
> create the schema files?
> I would suggest you look to see how the 'sessions' table was created and
> use that as the name for the relation.
> regards

I did not use the dbicdump script originally (these were tables from an old
app). I generated all schema classes using

perl -MDBIx::Class::Schema::Loader=dump_to_dir:lib/ -Mschemaname -e1

where schemaname was a DBIx::Class::Schema::Loader class specifying
connection and loader options (e.g. schema).

However, I've now tried the newer dbicdump script, and still get the same

[debug] Scheduler: Executing /cron/remove_sessions
[error] Scheduler: Error executing /cron/remove_sessions:
DBIx::Class::ResultSet::delete(): DBI Exception: DBD::Pg::st execute
failed: ERROR:  relation "sessions" does not exist [for Statement "DELETE
FROM sessions WHERE ( expires < ? )" with ParamValues: 1='1352925249'] at

The new classes are slightly different:
lib/GUS/Webapp/Sessions.pm (old)
lib/GUS/Result/WebappSession.pm (new)

but still they both call

and function with no issues for creating new sessions in the Pg storage,
updating the session_data, etc. They're only failing at the DELETE
statement, and from the error it is clear that they're failing to fully
qualify the table name.

I'm now CCing FLORA to see if he's aware of this behaviour and/or can help
see if it falls into the Session::Store::DBIC realm ...

Thanks again for all responses!

List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Reply via email to