pastebin - collaborative debugging

[13:08] <romanb> guilhermeblanco: a few small naming things. i'd name getSqlQuery = getSql(). seems better to me and is consistent with getDql(). and i'd prefer Doctrine_Query_SqlBuilder over just Builder.
[14:03] <guilhermeblanco> romanb: you probably misunderstand the enumParams issue
[14:03] <guilhermeblanco> we have to deal with 2 different situations
[14:04] <guilhermeblanco> 1- DQL is being processed now
[14:04] <guilhermeblanco> 2- SQL is recovered from cache (there's no DQL processment here)
[14:04] <guilhermeblanco> When 1:
[14:05] <guilhermeblanco> 1.1 - ParserResult stores the enumParams final array. Then, it populates the Query enumParams through: $query->_setEnumParams($parserResult->getEnumParams())
[14:06] <guilhermeblanco> 1.2 - SqlBuilder populates directly the Query enumParams
[14:06] <guilhermeblanco> When 2:
[14:06] <romanb> afk for a few minutes
[14:06] <romanb> will read through it
[14:07] <guilhermeblanco> There's no enumParams populated anywhere, since cache does not store it. My idea is to make 1.1 and to make CacheHandler store the enumParams too
[14:07] <guilhermeblanco> BUT
[14:08] <guilhermeblanco> 1.1 may require an aditional loop... something I DONT want to do
[14:08] <guilhermeblanco> I can consider something like a direct setter (protected) and getter (public) to enumParams in Query object
[14:10] <guilhermeblanco> I'm not saying to send $params to Parser, unless they're REALLY necessary...
[14:10] <guilhermeblanco> currently, the only one possible reason for that is the limit-subquery algorithm
[14:18] <romanb> concerning the caching of enumParams. i looked at CacheHandler and ParserResult and apart from $data they hold the same properties. so, why not remove the queryComponents and tablealiasmap from CacheHandler and make CacheHandler cache/restore ParserResult objects instead. makes a lot of sense to me
[14:19] <romanb> that way we cache the enumparams and any other stuff, too, since we cache the parseresult
[14:20] <romanb> get what i mean?
[14:21] <romanb> as i wrote in the wiki, lets deal with the limit-subquery thing alter once we have basic functionality working
[14:21] <romanb> *after
[14:29] <guilhermeblanco> I got it...
[14:29] <guilhermeblanco> but... where will the BL of CacheHandler be then? keep it but it'll be a factory of ParserResult?
[14:29] <guilhermeblanco> If yes... I'm totally +1
[14:31] <guilhermeblanco> I'm so-so to move the content of CacheHandler to Query... since it does some Mapper acesses that couple the API there...
[14:33] <romanb> yes, thats what i meant, the CacheHandler as a factory for ParserResult objects
[14:33] <guilhermeblanco> perfect
[14:33] <romanb> so the CacheHandler no longer needs querycomponents and tablealiasmap properties
[14:33] <romanb> it seemed duplicated to me
[14:33] <guilhermeblanco> I didn't thoguht that, but you're 100% sure
[14:35] <romanb> the problem with things like this:
[14:35] <romanb> ParserResult stores the enumParams final array. Then, it populates the Query enumParams through: $query->_setEnumParams($parserResult->getEnumParams())
[14:36] <romanb> is that we need to publicise methods on Query we dont want to have
[14:36] <romanb> i'D rather prefer putting such logic in Query then instead of doing that to be honest
[14:37] <guilhermeblanco> getEnumParams must be public
[14:37] <romanb> yes. i mean $query->_setEnumParams
[14:37] <guilhermeblanco> the only difference we'll have is that I'll remove the addEnumParam from Query_Abstract and I'll create a protected method called _setEnumParams
[14:37] <guilhermeblanco> no, since it'll be done inside Query object
[14:37] <guilhermeblanco> it'll not be public