-
Notifications
You must be signed in to change notification settings - Fork 43
mixing mappers #58
Comments
I'm not entirely sure, but I think that the create case is actually not that difficult, because we get the Anyways, here's the rough draft for a ChainMapper (lifted from #48 and slightly adjusted) to get the ball rolling: abstract class ChainMapper implements RdfMapperInterface
{
public function __construct(RdfMapperInterface $mapper)
{
$this->_defaultMapper = $mapper;
}
public function registerMapper(RdfMapperInterface $mapper, $typename = null)
{
if (is_null($typename))
{
$this->_defaultMapper = $mapper;
}
else
{
$this->_mappers[$typename] = $mapper;
}
}
abstract function getMapperForObject($object);
abstract function getMapperForRdfType($typeof);
public function getPropertyValue($object, PropertyInterface $property)
{
return $this->getMapperForObject($object)->getPropertyValue($object, $property)
}
// and so on....
} |
afaik rdf identifiers must be globally unique (correct @bergie?) so trying all possible mappers should be save if all behave as they should. its still a bit awkward, iterating over the mappers and trying to delete until there is no error, but should not be dangerous. |
You wouldn't have to go as far as trying to delete, trying to load (with If multiple mappers are a common use case, we might also go a bit further and add some sort of mapper ID to the generated identifier. F.x. we could have a |
or the chainmapper could enumerate the mappers and prepend the number to the id :-) though that would not play well when you want semantical ids on your entities. imho it would be the job of the mappers to make sure their id are unique. so i.e. the doctrine mapper should put the session name into the id if its not the default session. that way you won't have id collisions if the mapper in the lookup checks if there is this session information and if it matches the session it is connected to. |
True, having the prepend logic in the mapper would be a lot cleaner. We could then also allow passing the mapper ID on I'm not sure how a mapper could make sure that its ID is unique. I mean, it doesn't know about how many and which other mappers are registered, or am I missing something? |
gave this some more thought: we could have the registerMapper method have a parameter for an id prefix to use with that mapper. then the individual mapper would not need to know anything about this, and using the same mapper class multiple times with different configuration is totally transparent. that way the chain mapper can handle everything transparently, except for createSubject and when storing new entities where it would need to figure out which mapper to use. i can think of 2 options:
all other methods will only happen once the subject is resolved. the chain mapper will have to store the association between object and mapper in memory to know how to forward. does that make sense to you? if so i can start to code something... |
@flack: what do you think? |
@dbu Sorry, this got a bit drowned in my mailbox. I think the id prefix approach sounds good, I'm somewhat unsure about the solutions you propose, but I can't think of better ones either right now. Intuitively, I would go with solution 2, because it makes it more obvious what a mapper implementation has to actually do. Maybe we should call the second method |
yeah, i think 2. is the more elegant option. we could call the methods |
alright, so it seems like we're in agreement. Now the only thing that's missing is code :-) |
i will try to work on this while traveling to symfony con in warszawa... |
it would be great to be able to use more than one mapper at the same time, so that i can edit objects coming from different sources. this could be different databases, but also different types like phpcr, orm and symfony translation strings (see liip/LiipTranslationBundle#21)
i guess the best approach would be to have a ChainMapper that decides by type name which of the mappers to use. we would need to make sure that when a request comes in from the frontend we also know the type.
if you would want to use several mappers of the same class for different databases, it would mean that each type may only come from one database, never be in one or another database. (e.g. doctrine orm you would make sure that each mapper contains a different subset of your orm mapped entities). the ChainMapper could support the mixed approach and cycle through all mappers knowing about a type name, but then when storing a new entity it does not know with which of the mappers to store it.
The text was updated successfully, but these errors were encountered: