Talk:Editor campaigns/Persistence and domain layer notes
Latest comment: 10 years ago by AGreen (WMF) in topic Domain design
Domain design
editReally thorough docs, nice work! My feedback is mostly minor stuff:
Interfaces
edit- 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
edit- 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)