persistifying data
I found Propel today. The reason I found it was because I was looking for something somewhat similar to what Enterprise Objects do in WebObjects - basically, instead of writing SQL code I want to pass a bunch of variables (or an array, whatever) to an object and have it store it in the appropriate locations and take care of uniqueness and relationships where necessary. Propel does most of that. You can define the database schema in XML and Propel will automagically generate classes for you. It does introduce a compilation step, though. It also supposedly does persistence, but I haven’t gotten quite that far into it. The only real complaint I can see with it so far is that it doesn’t use PEAR DB or PDO - it uses its own thing called Creole - which limits its RDBMS support, and its architecture doesn’t lend itself quite as well to interfacing with things that aren’t RDBMSes (like XML files or LDAP or whathaveyou).
FWIW, PHP has something neat that’s being built into it that’ll do a lot of this too - SDO. It’s much the same concept as an EO but it’s part of the language (sort-of, it’s written in PHP) and should allow interfacing with stuff that’s not a relational database.
Still researching the ideas. Got some projects coming up at work that will lead me into dealing with this stuff more and more; in addition, it’ll be helpful when I start working on my stuff again (which should be Real Soon Now). Using either of these will save me from writing one myself, which would be excellent since I would end up getting stuck on writing a search engine that handles relationships between dissimilar data sources and all that haughty nonsense.
As an aside: dual monitors on the Mac Mini is out. I tried hooking up a dual-link (VGA+DVI) cable to my Mini - when you go to choose resolutions, it bongs confusedly when you tell it to refresh displays. The reason it Really Won’t Work: the port on that thing isn’t dual-link so there can only ever be one screen active at a time. When you choose a resolution not supported by your DVI display the VGA port kicks in and makes an attempt for it. Kinda sucks. Need a different monitor.
August 21st, 2005 at 7:21 am
Hi James –
(1) What do you believe Propel provides over and above current offerings like DBDataObject, DBTable, MDB2, et. al.? I’ve looked at Propel, and while it seems neat, I don’t see that it saves too much work. Be happy to be proved wrong.
(2) I’ve wrestled before with using an SQL-like APIfor querying LDAP, XML/XPath, etc., and have concluded that different data storage technologies benefit from their own specific APIs for querying (esp. because the query languages are so widely different). I’m curious as to your experience in dealing with this that leads to want the same API for them all. (Obviously it’s less to remember that way.
Thanks for writing up this entry, and sorry about your Mini video troubles.
– pmj
August 21st, 2005 at 10:20 am
Well, to be honest, those four do about the same thing, so you’re not really saving much by going from one to the other. Propel has a couple of nifty features like cascading deletes and updating related records automagically, which can be nice.
Really, I want two things out of PHP, one which is largely impossible unless you write a helper app that exists outside of PHP. I’d like to be able to lay out a data schema in something (XML, INI files, a can of pringles and some bubblegum, whatever) and be able to include dissimilar data sources and create relationships between them; I don’t necessarily want a SQL interface to work with, but rather a class with a Load/Store function that I can pass a list of fields to retrieve or data to store and have it generate the SQL query or the DN or whathaveyou and pump it back into the data store. The other thing I want is a way to cause objects to persist in memory. This is a scalability thing and one I want to explore just for geekiness’s sake and not because I write anything that’s that demanding.
It’s not something you can do too easily in PHP without having a helper application and a liberal use of shared memory or whathaveyou. Basically, wrap the DB stuff up with memcached and provide an easy-to-use unified interface for that. (As an aside I totally forgot memcached existed when I wrote this.)
As for the Mini, I’m not too worried about it.. it doesn’t officially support dual monitors anyhow
August 22nd, 2005 at 7:28 am
Regarding “persistence,” you might wish to look at things like Flickr, Yahoo, and Friendster … they make use of what they call a “shared nothing” architecture, where nothing is persistent between page loads. It appears to scale quite well; Flickr’s usage is quite high, after all.
http://www.google.com/search?q=shared+nothing+architecture
August 22nd, 2005 at 7:28 am
Oh, also, a bunch of ORM solutions in one place:
http://www.wiki.cc/php/ObjectRelationalMapping
August 22nd, 2005 at 7:36 am
Also: XML sounds great, until you realize you can do everything you need (and faster) using a PHP array. What you want is a system that uses an PHP array underneath; then you can use any translation service you want to convert XML, INI, YAML, or whatever else into an array.
(Sorry for the multiple replies.
August 22nd, 2005 at 8:33 pm
The shared nothing thing is new and interesting - thanks for the pointer to that.
I’m thinking between that and wrapping PEAR DB in a layer that will push stuff into memcache and a RDBMS - the big problem there is making the objects that exist in the cache known to anything that comes along, but I have some rough ideas about that.
As for the schema in XML thing, things that use it (like Propel) compile it into PHP arrays with Phing. Then (it seems) they use a standardized XML DTD to actually do the layout. It certainly leads itself to be a more portable solution with the speed benefits, since after compilation you have a PHP array but you have a portable XML document to use as well. None of this means much of anything if the XML schema isn’t useful outside of the app, though. So the real issue now is finding out if there are useful database management tools that can take in XML schemas, and finding out what format they’re in, and then finding something else to convert them into PHP arrays/etc…
August 23rd, 2005 at 4:41 am
Hi — You said, “So the real issue now is finding out if there are useful database management tools that can take in XML schemas, and finding out what format they’re in, and then finding something else to convert them into PHP arrays/etc…”
Or, alternatively, you could write your schema as a PHP array to begin with, then find tool that convert that array to XML. Work from the inside-out, as it were.