Jump to content

Talk:Editor campaigns/Persistence and domain layer notes

Add topic
From mediawiki.org
Latest comment: 10 years ago by AGreen (WMF) in topic Domain design

Domain design

[edit]

Really 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)Reply

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)Reply