Re^2: Reflections on the design of a pure-Moose web app...

So it sounds like the thing you're doing that's unusual is to store objects as JSON in a denormalized sessions table instead of normalized database tables. That can be good for some things. In general, I don't recommend it. Here are some reasons why:

Databases work hard to provide a sane model for concurrent access. You break that by using denormalized storage. It's usually ok if the cached objects are all related to a single user or read-only, but the chances for lost updates and other problems become high for shared read/write data. They can also get stale and miss updates in the underlying tables.
Serialized perl objects aren't easy to search. If you have no normalized storage of your shopping cart and you want to find all the carts that contain seminar 75, you have to walk through all carts in the system.
One reason that people often design from the database up is because the database is nearly always the bottleneck and the schema design has the largest affect on your application's scalability and performance. Trying to hide or bypass the database tables can lead to designs that don't take advantage of the details of your database's implementation.
Large sessions often perform badly. They can easily end up needing to serialize/deserialize lots of objects that aren't even used by the current request.

I don't mean to rain on your parade. Just pointing out some messes I've made before with sessions and caching of database objects. Apologies if I've misunderstood what you're doing.

Comment on Re^2: Reflections on the design of a pure-Moose web app...

Replies are listed 'Best First'.
Re^3: Reflections on the design of a pure-Moose web app... by locked_user sundialsvc4 (Abbot) on Mar 23, 2009 at 19:28 UTC
The application is built on top of a fully normalized and very well-constructed database. (That I didn't even have to construct! It was already there!) The advantage of the approach that I took in this application is that “almost all of the web application” did not have to be concerned with the vagaries of the structure of that database. The “Things” know how (and when...) to retrieve information from it, and to post information back to it. Having done so, they can retain the information, and make not-yet-permanent contemplated changes to it, without “hitting” the production database at all. I posit that such an approach provides for excellent separation-of-concerns within the application, and that it strictly avoids the problem of having the software design be subtly linked-to, hence dependent upon, the schema of that production database. Unstructured information of a reasonable size (i.e. a Perl object) can be stored separately for a reasonable time, in an altogether separate data-store, and then posted to the database only when, and if, necessary. Information is retrieved only on-demand, yet only the object need be aware of when such a “demand” has actually taken place. So... am I arguing any of your points? Absolutely not. Instead, I am just here to say: “Hey! Looky! This approach worked really well for me!” It is a very noticeable improvement that is going to stay at the top of my tool-bag for a while.
Re^4: Reflections on the design of a pure-Moose web app... by stvn (Monsignor) on Mar 23, 2009 at 20:01 UTC
To perrins point about concurrent access to the serialized JSON files, you might want to take a look at KiokuDB, the BDB backend provides full ACIDy transactional goodness and works even more transparently then MooseX::Storage does. -stvn	[reply]