Add SymQL-type methods to EntryManager

[nickdunn]

SymQL exists because at the time EntryManager was not fit for purpose. It still is not in my opinion, for the following reasons. If we can fix these, then SymQL becomes virtually redundant and EntryManager becomes awesome (and will make it almost the equivalent of a section datasource):

• an Entry's getData() returns an array of data indexed by the entry's field IDs. I'm forever rebuilding this array to use field handles instead, so that it becomes more readable and useful
• using EntryManager::fetch() one has to pass re-build JOIN and WHERE SQL clauses. EntryManager should have ways to build this itself. Presently this logic is bundled inside SectionDatasource. It had to be copied/pasted into SymQL
• an Entry cannot render itself as XML. Presently this logic is built into SectionDatasource. If I get entries back from EntryManager, I should be able to call asXML or something to generate the XML representation. I had to duplicate this from the SectionDatasource logic in SymQL

Now, this could be done in the core by amending EntryManager::fetch, but this method signature is already massive, and it would break backwards compatibility. So I suggest something like an EntryQuery class in the core which wraps up this nastiness and makes grabbing filtered entries from Symphony a core pleasure rather than an extension hack.

[nickdunn]

I've been thinking about this some more when updating SymQL for 2.3. Otherthings that EntryManager should be doing:

• resolving filters and building joins/where (class.datasource.php)
• creating entry XML (class.datasource.php)

My suggestion of adding an EntryQuery class was a poor one. Instead I think we could add an EntryManager::query method which works in a similar way to SymQL. The EntryManager already has methods for sorting, so the query arguments might be:

• section (ID or handle)
• fields (an array of IDs or handles)
• filters (an array of filters)
• limit
• page

This would internally build the where/joins and call EntryManager::fetch.

[nickdunn]

Add sorting into the mix too.

[michael-e]

I completely support Nick's ideas. It's a shame that it's so hard to access/output entries using custom code.

[nickdunn]

In relation to the discussion on PDO, I discovered this today — a DSL that performs joins behind the scenes for use in abstract table environments. Clever. Potentially very useful. The DSL syntax is almost identical to SymQL.

https://github.com/lichtner/fluentpdo

[brendo]

I will encourage @rowan-lewis to release his Symphony API abstraction layer as an extension so users can play with that. As for core work, lets focus our efforts on an awesome API in Next, not S2.