Hi all..
I'm trying to switch over to using the Seaside-Glorp package from the Cincom respository (on VW) and have my Seaside application doing the following : 1) Added GlorpConfiguration as part of the ancestry 2) Added WAResourcefulSession as the superclass for my existing session class 3) Edited the database settings via the Seaside config page for my app Now, perhaps I'm trying to access the database incorrectly but couldn't find any good examples lying around : self databaseSession readManyOf: myTable However, I get an exception down in the PostgresEXDI code when trying to access the 'system' which is not set for some reason.. Any ideas on what I'm missing? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Rick,
How are you creating the session? We send #sessionForLogin: to our descriptor system and that sets system on the session. HTH Steve Rick Flower wrote: > Hi all.. > > I'm trying to switch over to using the Seaside-Glorp package from the > Cincom respository (on VW) > and have my Seaside application doing the following : > > 1) Added GlorpConfiguration as part of the ancestry > 2) Added WAResourcefulSession as the superclass for my existing > session class > 3) Edited the database settings via the Seaside config page for my app > > Now, perhaps I'm trying to access the database incorrectly but > couldn't find any good examples lying around : > > self databaseSession readManyOf: myTable > > However, I get an exception down in the PostgresEXDI code when trying > to access the 'system' which is not set > for some reason.. > > Any ideas on what I'm missing? > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Steve Aldred wrote:
> Hi Rick, > > How are you creating the session? > We send #sessionForLogin: to our descriptor system and that sets > system on the session. > I'll have to take a look.. I'm assuming that if I've got 50 active separate connections going that it will not have 50 active database connections at the same time -- I was thinking about that this morning.. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Rick Flower wrote:
> Steve Aldred wrote: >> Hi Rick, >> >> How are you creating the session? >> We send #sessionForLogin: to our descriptor system and that sets >> system on the session. >> > I'll have to take a look.. I'm assuming that if I've got 50 active > separate connections going that > it will not have 50 active database connections at the same time -- I > was thinking about that > this morning.. Whether you pool one or more DB sessions or have one per user depends very much on what your application does. In the past we've used techniques such as having a single query connection, which everybody uses, and one or more update connections. If the update connection was busy when a second user needed to update we'd create another one. This let us get away with as few connections as possible without users having to wait unnecessarily. Of course it depends on your security and locking requirements as to how well that will work. Steve _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |