Various performance improvements (cache entities, entity and property de...

[andig]

...finitions, use Iterators instead of callbacks)

[jahir]

tnx. Only difference to #215 is DataController line 129, right?
AFAICS this disables caching for POST entirely, which is a little pity, because there are much more POSTs than GETs (at least on my system), so the caching primarily helps the frontend.

I'm not sure why caching works for get but not for add. The add method wants a channel and the get an entity, but that shouldn't be the problem (as we EntityController::getSingleResult stores in the cache what it returns). If it's easy to make it work for both, could you do that? The class looks kind of scary, anyway...

And could you add some comments to the new option in volkszaehler.conf.php, maybe with some description what is cached in which case.

[andig]

AFAICS this disables caching for POST entirely,

Partially true. Disabled for POSTs not using JSON (i.e. via GET).

which is a little pity, because there are much more POSTs

True but not a problem the user typically encounters.

To solve, either:

1. change DataController->add to always use SQL instead of ORM (as the JSON solution is already doing) or
2. make clients use POST requests

I'd he happy to add support for 1) but it feels like a move in the wrong direction. Would again be faster though.

[jahir]

Partially true. Disabled for POSTs not using JSON (i.e. via GET).

Well, my clients use POST but with URL parameters :)

1. change DataController->add to always use SQL instead of ORM (as the JSON solution is already
   ...
   I'd he happy to add support for 1) but it feels like a move in the wrong direction. Would again be faster though.

I guess we should decide at one point if we want to keep the ORM (and use it everywhere) or get completely rid of it...
OTOH, I care more about about functional uniformity, e.g. the add method should not behave differently between GET &action=add and POST

[andig]

Well, my clients use POST but with URL parameters :)

Thats not the problem.

OTOH, I care more about about functional uniformity, e.g. the add method should not behave differently between GET &action=add and POST

It does not. The distinction is JSON in POST body or not. Reason is that only POST body can carry multiple timestamp/value pairs. It's easy enough to change the other case to SQL as well.

I guess we should decide at one point if we want to keep the ORM (and use it everywhere) or get completely rid of it...

Probably not as the whole entity management is quite complex and Doctrine has clear advantages. Why not use pure SQL for the parts where it matters (e.g. Aggregation)?

[andig]

@jahir Updated DataController to always use SQL- we gain consistency and performance and loose some old code.

This should be the version we commit.

[jahir]

nicely done, thanks! :)