Hi guys,
I'd like to announce a new Propel sub-project: LinguaFranca.
LinguaFranca's goal here is to provide support for the
reverse-engineering functionality that has hitherto been provided by
Creole. It would also be nice to have a general-purpose
reverse-engineering tool available for PHP. So a sub-goal is to provide
a toolkit that can be used standalone by any app out there that wants to
get an OO representation of a database's structure.
The intent is to move the metadata stuff out of Creole into this new
project, which will then be a dependency for both Creole and Propel.
Tony suggested this when we got together for beer recently, and I think
it's a simple solution that makes a lot of sense.
Originally, I was thinking that we'd use PDO for the API abstraction in
this tool, although I'm not sure that PDO will provide a rich enough API
to all the drivers for accessing their metadata (although I don't think
there's anything in the Creole metadata currently that PDO can't
accommodate). If we do use native drivers for extracting the metadata,
we should at least support the PDO connection url (dsn) format.
This project will have a complete OO model that will represent the
database structure, more complex than Creole's current metadata
(DatabaseInfo, TableInfo, etc.) classes, and more like Propel's database
model classes. Propel will probably still need some sort of model
classes, since Propel is additionally concerned with moving database
model to & from XML, but those model classes could probably become a lot
simpler.
If anyone has suggestions (I know Sven was thinking about this solution)
for a clean way to reduce code while keeping things functionally
separate, please let me know! Obviously, I'd greatly appreciate any
help in development too. Much of the code does exist now in Creole and
will simply need to be modified to support a richer object model. We
should probably think about some practical things like "namespacing" now
too. Maybe "LF" class prefixes ... or ... ? As much as I hate that in
PHP, it's pretty necessary ... especially considering that classes like
"Table" are not exactly anomalies in the DB app world :)
Hans
|
