Guest
Public paste!

guilhermeblanco

By: a guest | Mar 20th, 2008 | Syntax: None | Size: 3.62 KB | Hits: 77 | Expires: Never
Copy text to clipboard
  1. [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.
  2. [14:03] <guilhermeblanco> romanb: you probably misunderstand the enumParams issue
  3. [14:03] <guilhermeblanco> we have to deal with 2 different situations
  4. [14:04] <guilhermeblanco> 1- DQL is being processed now
  5. [14:04] <guilhermeblanco> 2- SQL is recovered from cache (there's no DQL processment here)
  6. [14:04] <guilhermeblanco> When 1:
  7. [14:05] <guilhermeblanco> 1.1 - ParserResult stores the enumParams final array. Then, it populates the Query enumParams through: $query->_setEnumParams($parserResult->getEnumParams())
  8. [14:06] <guilhermeblanco> 1.2 - SqlBuilder populates directly the Query enumParams
  9. [14:06] <guilhermeblanco> When 2:
  10. [14:06] <romanb> afk for a few minutes
  11. [14:06] <romanb> will read through it
  12. [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
  13. [14:07] <guilhermeblanco> BUT
  14. [14:08] <guilhermeblanco> 1.1 may require an aditional loop... something I DONT want to do
  15. [14:08] <guilhermeblanco> I can consider something like a direct setter (protected) and getter (public) to enumParams in Query object
  16. [14:10] <guilhermeblanco> I'm not saying to send $params to Parser, unless they're REALLY necessary...
  17. [14:10] <guilhermeblanco> currently, the only one possible reason for that is the limit-subquery algorithm
  18. [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
  19. [14:19] <romanb> that way we cache the enumparams and any other stuff, too, since we cache the parseresult
  20. [14:20] <romanb> get what i mean?
  21. [14:21] <romanb> as i wrote in the wiki, lets deal with the limit-subquery thing alter once we have basic functionality working
  22. [14:21] <romanb> *after
  23. [14:29] <guilhermeblanco> I got it...
  24. [14:29] <guilhermeblanco> but... where will the BL of CacheHandler be then? keep it but it'll be a factory of ParserResult?
  25. [14:29] <guilhermeblanco> If yes... I'm totally +1
  26. [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...
  27. [14:33] <romanb> yes, thats what i meant, the CacheHandler as a factory for ParserResult objects
  28. [14:33] <guilhermeblanco> perfect
  29. [14:33] <romanb> so the CacheHandler no longer needs querycomponents and tablealiasmap properties
  30. [14:33] <romanb> it seemed duplicated to me
  31. [14:33] <guilhermeblanco> I didn't thoguht that, but you're 100% sure
  32. [14:35] <romanb> the problem with things like this:
  33. [14:35] <romanb> ParserResult stores the enumParams final array. Then, it populates the Query enumParams through: $query->_setEnumParams($parserResult->getEnumParams())
  34. [14:36] <romanb> is that we need to publicise methods on Query we dont want to have
  35. [14:36] <romanb> i'D rather prefer putting such logic in Query then instead of doing that to be honest
  36. [14:37] <guilhermeblanco> getEnumParams must be public
  37. [14:37] <romanb> yes. i mean $query->_setEnumParams
  38. [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
  39. [14:37] <guilhermeblanco> no, since it'll be done inside Query object
  40. [14:37] <guilhermeblanco> it'll not be public