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)

The ORM classes we have in core follow the Active Record pattern and are badly named. They are also not a very good implementation of this pattern, and have resulted in some code suffering from classical pitfalls one needs to watch out for when using Active Record. It's unfortunate the "ORM" code was accepted into core. --Jeroen De Dauw (talk) 17:43, 11 January 2015 (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)

Feedback

I like the notion of seperating domain and infrastructure concerns. Having a data mapper is not a prerequisite for this though, and MediaWiki is very far from having a domain model structure. This is not an argument against having a data mapper, but one against not seperating the mentioned concerns because of not having, or objecting againt having, a data mapper.

I'm concerned about things being reinvented once again. Let's please use existing well supported solutions when available. --Jeroen De Dauw (talk) 17:53, 11 January 2015 (UTC)