guilhermeblanco

[15:05] <guilhermeblanco> romanb: one last question before I leave

[15:06] <guilhermeblanco> CacheHandler actually handles the 2 types of cache in Query object

[15:06] <guilhermeblanco> since now CacheHandler will return an instance of ParserResult in all situations...

[15:07] <guilhermeblanco> how will it be the call to get the stored ResultSet (in the case that user decided to do a resultCache)?

[15:07] <guilhermeblanco> following the strict API, it should be getSql()

[15:07] <guilhermeblanco> since the equivalent to getData() will be getSql()

[15:08] <guilhermeblanco> any suggestions?

[15:11] <romanb> i think you're right. it does not seem so nice to have getData() in a ParserResult since it has nothing to do with it actually. need to think about it. im sure we'll find a good solution. this change (caching ParserResults) is definitely the right step.

[15:12] <romanb> maybe we can have QueryResult that extends ParserResult and has $data and getData ? that just a really quick idea to get it separated

[15:12] <romanb> may not be a good one

[15:12] <guilhermeblanco> I can create an alias getData() { return $this->getSql(); } to make the API eye-candy...

[15:12] <guilhermeblanco> OR

[15:12] <guilhermeblanco> EXACTLY

[15:12] <romanb> since the result cache is actually an extended version of the query cache

[15:12] <romanb> literally

[15:12] <guilhermeblanco> yeah

[15:13] <guilhermeblanco> and then I can do:

[15:13] <guilhermeblanco> QueryResult extends ParserResult { function getSql() {}  function getData() { return parent::getSql(); } }

[15:13] <guilhermeblanco> OR

[15:14] <guilhermeblanco> class ParserResult extends ResultAbstract {} class QueryResult extends ResultAbstract {}

[15:14] <guilhermeblanco> which may be the best solution

[15:15] <romanb> but its a matter of fact that the result cache stores all the information the query cache stores + the data

[15:15] <romanb> or not? this sounds like direct inheritance for me

[15:16] <guilhermeblanco> no... it stores either the SQL or the ResultSet... no both

[15:16] <guilhermeblanco> *not

[15:16] <romanb> ah ok right. it doesnt need the sql

[15:16] <romanb> then thats better yes

[15:16] <guilhermeblanco> ok... another pastebin... =)

[15:16] <romanb> but AbstractResult instead of ResultAbstract

[15:17] <romanb> actually... according to current coding standards

[15:17] <romanb> Result_Abstract

[15:17] <romanb> but we cant keep that anyway

[15:17] <romanb> with namespaces we would go AbstractResult

[15:17] <guilhermeblanco> I am imagining Result_Abstract, Result_ResulSet, Result_Parser

[15:17] <romanb> in namespace Doctrine::Query

[15:18] <guilhermeblanco> ok... I'd go with your suggestion... better than mine

[15:19] <romanb> i'd prefer AbstractResult/ParserResult/QueryResult

[15:19] <romanb> these names will survive namespaces, too

[15:19] <romanb> the others wont