Solves the issue with having a site not using the built in PDO (case in point, I'm building a site entirely on Redis with a separate vendor library that isn't part of PICKLES)
Rearranged methods as well, they needed to be in alphabetical order. In the case that I need more distance related conversions, I'll move that method to it's own class.
Used to be very rigid in that each URI had to map to a single module. Now the inclusion of dots in the URI allow you to have multiple end points in a single file. /user/edit and /user/edit.save both resolve to /modules/user/edit.php
Probably should make it a part of the model as well, assuming it doesn't already do that, pretty sure it doesn't. Would help me as one of my sites I need to migrate a ton of code, so being able to flip models on one by one would be excellent.
Simplified logic by only checking one variable. Since "1" is a string but also returns true for being an integer, I swapped the is_string out for an !is_int
Previously new Model(array(1, 2, 3)); would results in a query like SELECT * FROM table WHERE 1 AND 2 AND 3; which would typically result in an out of memory error depending on the number of rows in the table (as all would be returned). Added detection for an array of integers and forces that to be considered new Model(array('id' => array(1, 2, 3))). As I type this I think I need to go back and make an additional change.
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.
