Talk:Editor campaigns/Persistence and domain layer notes

Domain design

Really thorough docs, nice work! My feedback is mostly minor stuff:

Interfaces

• The web API should return ID references to campaigns and users, but don't you think the PHP API should return objects?
• "UrlId" is difficult to grok because it looks parallel to the other IDs. Maybe call that "UrlKey" or something?
• I think we have to spec out the welcome page thing a bit more--it just occured to me that campaigns are probably used across wikis. For the same reason, the API should probably return a relative-protocol URL or something. Interwiki references are still unstable across wikis.
• How will you use the "exists-" functions? Seems like that is inviting race conditions.
• I forget the use case for removeParticipant. Same with getTimeLeft.
• I still think the "fields" argument to getters is overkill, and we should just return all columns.
• Did you have any thoughts about namespacing campaigns so the same short key can be reused in different contexts? I fear a situation where people have to start using crazy, long strings in search of a unique name.

Design

• DataMapper or ActiveRecord are probably overkill here, at least until we try to integrate with a semantic store, so you might want to explicitly state that you're trying to illustrate general improvements to the MW persistence layer.

Adamw (talk) 00:01, 29 March 2014 (UTC)

Thanks a lot!! Point by point:

• Returning objects instead of IDs: Yeah, that is what an OO domain model is supposed to do. I wasn't sure it was worth the performance cost, though. I'll look into it.
• UrlKey instead of UrlID: done.
• Spequing out the welcome page: basically done now, I think. Changed field from WikipageID to WikipageTitleText.
• Exists- functions. These are for preliminary checks that no other campaigns have the same URL key or name before attempting to create a campaign or update those fields. They won't be used in locking reads; rather the commit will throw an exception if there is an actual collision. If that happens, a different string should be chosen. Maybe we should add an option to read from DB_MASTER? Also, a web API could be added to provide AJAXy real-time checking in a UI.
• Use cases for removeParticipant and getTimeLeft: when a user decides to leave or is forcibly removed from a campaign. TimeLeft is null if they're still a participant, and is set when they leave. Mentioned here. I think there's probably not much of a real use case in the first iteration, though. Also, the general mechanism of recording time joined and time left will support reconstructing a campaign's evolution over time (later on).
• Just returning all columns instead of letting the interface consumer select only the columns needed: OK, that's quite possible. Maybe I could look into how significant it is performance-wise?
• Campaign name namespaces: good point. I hadn't thought about it. Suggestions are welcome!
• Mentioning that the heavyweight data mapper pattern is used partly to demonstrate possible general improvements to MW: done.

AGreen (WMF) (talk) 05:53, 29 March 2014 (UTC)