Elxis CMS Forum
Support => Database => Topic started by: dnglaze on June 11, 2008, 22:22:10
-
Just out of curiosity, has there been any discussion of moving the database abstraction layer of Elxis away from ADOdb and to something like Propel or Doctrine? Both of those options offer object abstraction from the database level and offer drivers that support pretty much every database out there. They both let the programmer step away from the SQL statements and just worry about the business logic of the application. You also can avoid having embedded SQL statements that control what databases are compatible with the Elxis system. I figure, the CMS itself should not have to worry about the database it is on top of, but should instead worry about adding new functionality. The database work should be done by some abstraction layer. The way ADOdb is currently setup, this is impossible. Propel and Doctrine, though, do offer this abstraction. The biggest problem with trying to do this with Elxis is that changing the database abstraction layer is a lot of work. Thoughts?
-
I dont know propel, I have heard about doctrine. I will search the Internet for both of them tomorrow morning to get more info. As you said changing the abstraction layer is A LOT of work. Also Elxis has been based a lot on ADOdb not only for the database queries. ADOdb has many help classes (like datadict, perf, pear, xmlschema, etc) which Elxis uses and are very-very helpful. Do doctrine and propel have such features?
-
Doctrine is a database abstraction I haven't worked with much, but I believe it has some similar, if not better according to some, abilities to that of Propel. Propel requires that the user using the system sets up a schema in XML for it to use for both building the SQL to insert into databases to create tables and for querying. It then provides objects as an interface to the database. By doing things like BaseObject.getId(1), it returns an object of type Object that has methods like object->getName() that returns that contents of that column for that object. It basically lets the developer ignore SQL altogether because the XML is the only thing propel needs to create SQL that works with pretty much any database. It also has data loading capabilities from XML documents as well. A lot of this does need to happen on the command line, meaning, I don't know if they have an interface from PHP to do the data loading and what not, though they probably do. Altogether, the only thing required of the developer is to know that names of the objects that represent the database tables as well as writing the XML to represent the database and the data. You can see more on Propel at http://propel.phpdb.org/trac/ (http://propel.phpdb.org/trac/) and more on Doctrine at http://www.phpdoctrine.org/ (http://www.phpdoctrine.org/). Propel is the ORM with the higher version number, though this doesn't necessarily mean anything.
By using these object interfaces, the end result is a more layered system that becomes less locked into a certain way to do things. This gives a much more open system much like that of the OSI or TCP/IP models where each layer can be changed as long as the interfaces remain the same.
-
I love Propel and one of my clients uses it as the foundation for their application. My main problem with Propel is that is requires applications on the server, xml schemas, etc to be used, and this is difficult on a lot of servers depending on your knowledge of servers and/or the permissions you have on your server. I now use DABL, http://manifestwebdesign.com/developer-resources/database-abstraction-layer/ (http://manifestwebdesign.com/developer-resources/database-abstraction-layer/) which has an almost identical API, but generates all of the classes with a php script instead of a bunch of other programs. The only thing you need to run it is PHP 5 with the PDO extension, and it is much lighter than Propel. Currently it is built for mysql, but could be modified to work for any database without changing the API.