ClayDB 2: Prototyping and Ideas for ClayDB 3
The goal for ClayDB 2 has been to expand the Data Dictionary capabilities and build a better way to create and manipulate database tables on any supported database. I've been prototyping the PDO MySQL Data Dictionary within ClayDB to reach that goal. The Data Dictionary has been expanded quite a bit and allows a range of table manipulations. It is not fully tested, so I haven't moved on the other databases' datadicts yet. I have been comparing SQLite, PostgreSQL, MSSQL, and MySQL while developing the prototype in MySQL. All of them are very different, so it has been a balancing act. It looks like PostgreSQL will miss the most functionality, mainly because there is so much there that doesn't translate to the other databases. I've been working with the dummy application to test ClayDB 2 and hope to soon make the necessary application changes across the board, followed by a merge back into the master branch.
Like I said before, ClayDB 2 has been all about improving the datadict classes, but I couldn't resist adding a feature to the adapters. ClayDB 1 only returned arrays for result sets. In ClayDB 2 I've added a getObject() method that returns either an object or an array of objects. I don't plan to change a lot more than that on the adapter side, although I have improved the adapters' abstraction and interface. I may make a few other changes, but I do not plan to mess with compatibility on the adapter side with this version change. The datadict changes will be enough work to bring everything up to date. I have thought about some ideas for ClayDB 3 though.
I think the main feature it is missing, as far as popular features go, is a model system. Now I don't believe ClayDB should be responsible for ORM or anything that complex. Its purpose is to make connections and queries to varying databases easier and it does that fairly well. Instead, I'm considering offering an abstract class that allows someone to implement models and, with some expansion, object-relational mapping. The class would allow someone to implement traditional models (at the framework level) or allow you to work with an object model from within an application API. Now within ClayCMS I have been planning to migrate much of the ClayCMS libraries to application libraries, so there's a little push and pull there. I believe the framework level libraries should be used to implement features within applications, instead of carrying the load themselves. So, as of today at least, ClayDB 2 will focus on improving the Data Dictionary, while ClayDB 3 will likely focus more on data handling and moving more toward object models.
Log in to comment