Hi everyone,Doctrine 1.2 dropped support for strings in attribute names and values, without deprecating the functionality first in Doctrine 1.1 (which in my opinion is typical of this project, but that's a different story).
That means that this:
$con->setAttribute('validate', 'none');
which in Doctrine 1.0/1.1 essentially did:
$con->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_NONE);
just does not work anymore, breaking existing code, but why would they
care...
I've been thinking about this for quite a while now (and got the occasional outburst of anger and frustration with Doctrine during that). The problem is that there are all kinds of possible values for attributes:
$con->setAttribute(Doctrine_Core::ATTR_VALIDATE, Doctrine_Core::VALIDATE_NONE); $con->setAttribute(Doctrine_Core::ATTR_PORTABILITY, Doctrine_Core::PORTABILITY_ALL ^ Doctrine_Core::PORTABILITY_RTRIM);
$con->setAttribute(Doctrine_Core::ATTR_QUOTE_IDENTIFIER, true); $con->setAttribute(Doctrine_Core::ATTR_TABLE_CLASS, 'MyTableClass');$con->setAttribute(Doctrine_Core::ATTR_RESULT_CACHE, new Doctrine_Cache_Db(array('connection' => Doctrine_Manager::connection(new PDO('sqlite::memory:')))));
The only solution I can think of right now that would solve this properly is using literal expression strings for values, so to configure the above, you would do:
<ae:parameter name="attributes"><ae:parameter name="Doctrine_Core::ATTR_VALIDATE">Doctrine_Core::VALIDATE_NONE</ ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_PORTABILITY">Doctrine_Core::PORTABILITY_ALL ^ Doctrine_Core::PORTABILITY_RTRIM</ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_QUOTE_IDENTIFIER">true</ ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_TABLE_CLASS">'MyTableClass'</ ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_RESULT_CACHE">new Doctrine_Cache_Db(array('connection' => Doctrine_Manager::connection(new PDO('sqlite::memory:'))))</ ae:parameter>
</ae:parameter> There are two obvious problems with that: 1) how to validate the expression 2) how to evaluate the expressionFor Agavi 1.1, we'll introduce special behavior for configuration compliation where the config handler can talk to the class in question for resolving of config parameters and other things; for instance, AgaviPropelDatabase could do much of the merging, version juggling etc at compile time rather than runtime. The same applies to AgaviDoctrineDatabase, and that could *maybe* enable point #2 above, although the idea so far was to only have all parameters filtered and changed, not to have those "callbacks" actually determine the exact code to be generated, which would be much, much harder to do. Either way, validating the expressions won't really be possible, so a typo in there would lead to very obscure parse errors in the generated database configuration. Plus, having to put strings in quotation marks would be awkward in my opinion (but necessary in order to avoid conflicts with literals like "true" or "Doctrine_Core::VALIDATE_NONE", both without quotation marks of course).
In any case, for Agavi 1.0, that option isn't on the cards. I'll now change the code so that it checks if the key and/or value string is defined as a constant, and if so, run it through constant(). That'll allow the first, third and fourth of the attributes above to be configured like this:
<ae:parameter name="attributes"><ae:parameter name="Doctrine_Core::ATTR_VALIDATE">Doctrine_Core::VALIDATE_NONE</ ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_QUOTE_IDENTIFIER">true</ ae:parameter> <ae:parameter name="Doctrine_Core::ATTR_TABLE_CLASS">MyTableClass</ ae:parameter>
</ae:parameter> (note how the table class does *not* have surrounding quotation marks).The others would have to be done through subclassing AgaviDoctrineDatabase, which like in case of the caching adapters is arguably inconvenient as that might be one of the things you really want to configure on a per-environment level.
The big question of course is whether that might actually be enough, because the other cases are sufficiently special and/or rare that people will subclass AgaviDoctrineDatabase anyway.
Another thing I have been considering is allowing people to specify a class/function that is called during initialization of a connection which would then deal with the above; I'm currently leaning towards doing it that way, as it removes a lot of complexity.
Any kind of thoughts/feedback/input welcome. I'd really like to have a long-term solution for this, which is why making a map of Doctrine's attributes and then specifiying the behavior respectively is completely out of the question - the project changes too quickly and there is no attention to quality, backwards compatibility or API stability for that to be viable.
- David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Agavi Dev Mailing List [email protected] http://lists.agavi.org/mailman/listinfo/dev
