Talk:Requests for comment/Data mapper

Concerns
I am mostly concerned with adding something new into core that isn't going to be used, but still needs to be maintained. We already have the ORM interface in core that barely anything uses, why should we add yet another thing?

The RfC says that this could "even disappear at any time" which is probably the biggest turnoff for me. Why would I want to write any code that uses something that could just go away, requiring me to re-write my code? I'll just stick with what works and what I know will work in the future. Legoktm (talk) 16:43, 10 September 2014 (UTC)
 * Thanks!!! Sorry if the RfC isn't clear—what I meant is that initially it could be considered not a stable feature, until tried out and iterated a bit. After that it, if desired, it could certainly become a permanent fixture.
 * Regarding the unused ORM currently in core: I don't think that's an indication that ORM isn't useful. A data mapper is a reasonably different approach to ORM than the one now in core, and by iterating and working with a diversity of use cases, I think we stand a good chance of developing something that we like and that improves our code. --AGreen (WMF) (talk) 20:16, 10 September 2014 (UTC)

Some overlap with RESTBase
There seems to be some overlap with the functionality we are working on in RESTBase. The biggest difference seems to be the style of the interface (array objects with paths vs. PHP objects). This interface can definitely be implemented on top of REST objects, but we should consider the cost for consistency and flexibility. The REST style interface lets us mix storage requests with other service requests and execute those in parallel, while this interface is more focused on storage only. There could be interesting intermediate solutions though, with PHP value objects automatically being converted to / from JSON. -- Gabriel Wicke (GWicke) (talk) 17:12, 10 September 2014 (UTC)