in reply to Re: To cache or not to cache
in thread To cache or not to cache

Ive writen a fully functional persistent framework which was finished just some weeks ago. My experience was:

1. I tried Class::DBI and Tangram first, but they were too poor in resources for the project we were creating.

2. Decided to create my own persistence class. Started simple, finished complex (3000 lines of intensive programing).

3. Ive found the need to cache all schema definitions, permissions, user info, etc. Choosed MLDBM with Storable and BerkeleyDB, just becouse it is faster than anything else (Cache::*, MySQL, etc). There iss no cache os table data in the system, but only system/schema definitions.

4. My persistence class loads up all columns of the row into memory executing a "SELECT *", with no need to access Postgres latter. This data is stored in the object properties. When the object is destroyed, all data is destroied and must be instantiated again with a new SQL statement in the next page loaded (its a web app). But the schema information (column names, types, sizes, etc.) is cached.

5. The performance is quite nice.

Diego de Lima

Replies are listed 'Best First'.
Re^3: To cache or not to cache
by perrin (Chancellor) on Mar 15, 2006 at 21:19 UTC
    I think you might have been happy with Rose::DB::Object. It's a more complete and faster system than the others.