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.
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.