Am 23.06.2014 15:45, schrieb Jeroen De Dauw:
Hey,
Resolving redirects and retrieving entities are two different things. Sometimes you want to do both, sometimes just one. Trying to create a general solution by adding one of them to an existing interface dedicated to the other is bound to end up being problematic, as your email illustrates. I suggest only putting them together where there is need to do so, and create new objects and interfaces based on the needs encountered there. Forcing the existing interface to know about redirects would be repeating the mistake of putting the revision id in there, though in this case it'd be worse.
Well, the thing is, in many cases it's supposed to be opaque. Most code should just be based on "I have an ID, give me the entity", and never think about redirects. They should just work.
However, in some cases, we want to explicitly specify whether redirects should be resolved or not. E.g. wbgetentities should have a flag for that. And performing entity edit operations on a redirect should fail.
So, code that knows about redirects should use a different interface than code that doesn't care? Is that what you are saying? This *mostly* aligns with code that uses EntityLookup (doesn't care) and EntityRevisionLookup (does care).
Maybe EntityLookup should always opaquely resolve redirects, while EntityRevisionLookup should do so when requested. That makes sense from the perspective that the context in which the revision ID is relevant is generally also context in which redirects should be considered explicitly. I'd have to poke around to see how far that correlation goes.
What do you think of tying redirect handling to explicit revision handling?
-- daniel
PS: yes, resolving a redirect is not the same as getting an entity. getting an entity may however involve resolving a redirect.