Selects done against a primary key will automatically cache to Memcached (haven't tried it, but it should fail gracefully) indexed by the model name and the primary key ([NAMESPACE-]MODEL-PKEY). Any updates or deletes against the same primary key will purge the cache automatically. The major caveat here is the case of mass updates which would result in stale data. As it stands the data is being cached for a mere 5 minutes, so this multiple row update scenario would be short lived but ideally, I'll be pushing back the time to live on the cache and/or making it something that's configurable. If you have to do mass updates, you're probably doing them with a cronjob and should just be flushing all of the cache in that scenario (as it would be nearly impossible to detect the affected keys and purge them all).
Also obliterated the getters and setters in the Database class after running some tests against their speed in comparison to getting and setting the variables directly
Seems there's a scenario within PICKLES that provides a backtrace report that lacks a class name (even though the file being referenced is a class). If no class is set it's simply omitted.
One of @geoffoliver's suggestions, default methods that are exclusive to the user's permission level. Named __default_ROLE(). No more conditionals in the code since you can now isolate the logic
Now you can set variables in the module itself and have them returned to the template instead of needing to explicitly return the data. Will come in handy in scenarios where you've extended another module and want to retain it's return data. Previously you had to set a variable and then add to that and return it from the child class.
As a developer you still need to code for it (it's shown at work in the bootstrap) but you can use the variable to toggle fluid and fixed right from the module itself
I never use them, there's a link for the JSON one in the convert class if anyone really needed it. Mongo support's been dropped for a while so there was no need for that one either.
Magic getter was overwriting the value because it was == null. Updated Module to check if the value isset() and if not, try to load from the config or set to false.
Automatically inject the creation, update, and delete timestamps as well as which user performed the action. Rows can now be logically deleted and there are no more named parameters just question mark syntax.
The ID variable was used to map the table's UID so the model could inject it in properly. Added a new variable named columns that is an array of the key columns. Currently contains ID, Created at and Updated at columns. The timestamp columns will soon be injected into the queries and if the value is set to false, will skip it.
There wasn't much to drop as it was never fully integrated. Unfortunately the only things that end up being fully integrated are the things that I actually use. Maybe someday MongoDB, maybe someday.
Memcached is considered a bad choice for sessions as when it's full, it purges old keys and could end up purging user sessions. You can solve this with more memory, but it's a ton easier to keep it on disk in a single server setup and in the database when running a cluster.
I develop on OSX, I run sites on Linux. Safe bet that if I'm running PICKLES on OSX that I'm in a development environment and it's a safe bet to jar those pickles
