COmanage Developers List

[Benn Oshrin <>]

By way of an update, I did a quick build with DBAL as part of setting up 
Registry PE (aka Registry v5) and am pretty happy with it so far. It 
doesn't actually have a schema format (ie: no equivalent of axmls) but 
it has everything else (including the ability to diff two database 
descriptions and generate the SQL required to bring them into sync), so 
building a (json) schema to convert to DBAL's internal format was 
actually pretty simple. There was one bug with postgres sequences that 
was easy to workaround (an excess DROP SEQUENCE statement is generated), 
and I'll probably submit a PR for it eventually.

It also has enough basic SQL query tools to replace the equivalent ADOdb 
calls in Match, so we should be able to use it to completely replace 
ADOdb there, too. These tools will also be useful in transforming data 
when upgrading to Registry PE.

It doesn't support nearly as many databases as ADOdb, but it does 
support a superset of the Cake-supported databases, so practically 
speaking we're covered.

The documentation is really, really terrible. I mean, you'll appreciate 
just how great the Cake documentation is in comparison. Even the API 
documentation is terrible. (OK, so the function takes an array $flags 
and an array $options... what goes in each? No idea.) Fortunately, we 
won't need it much, and I've already dug up most of the details we'll use.

The Doctrine Project seems to have a better sustainability path than 
ADOdb. So all in, I think this is the direction unless we run into a 
blocker. We should probably consider ADOdb to be in "absolute minimal 
maintenance" standpoint from a project perspective.

I'm trying to get an initial commit of Registry PE pushed soon so 
everyone can start working on it. Reusing a bunch of Match code has 
significantly sped up the process. (Sorry, Arlen, I just copied all the 
UI stuff again. It should be easier to clean up this time, though.)

Thanks,

-Benn-