Page MenuHomePhabricator

Add `badges.edit` and `` to Conduit API

Authored by lpriestley on Apr 5 2016, 6:26 PM.



Ref T10671

Test Plan

Open Conduit application, open badges.edit or, create, edit, or query for a badge.

Diff Detail

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

lpriestley updated this revision to Diff 37646.Apr 5 2016, 6:26 PM
lpriestley retitled this revision from to Add `badges.edit` and `` to Conduit API.
lpriestley updated this object.
lpriestley edited the test plan for this revision. (Show Details)
lpriestley added a reviewer: epriestley.
epriestley accepted this revision.Apr 5 2016, 6:29 PM
epriestley edited edge metadata.
epriestley added inline comments.

Small copy/paste issue, paste -> badge.

Also arhived is missing a letter, maybe an issue in Paste too?


Omit this; PasteContent doesn't make sense in the context of badges. Just return array(), badges have no attachments for now.

This revision is now accepted and ready to land.Apr 5 2016, 6:29 PM
lpriestley updated this revision to Diff 37647.Apr 5 2016, 7:56 PM
lpriestley marked an inline comment as done.
lpriestley edited edge metadata.

Copy pasta


Aren't awards attachments?

"Attachments" are a generic way to ask for extra data when you issue a query.

For example, you can ask for the "projects" attachment to get information about project tags, or the "subscribers" attachment to get information about subscribers. These attachments are automatically provided and work on any object which can be tagged with projects or have subscribers.

Some applications provide additional attachments. For example, Paste provides a "paste content" attachment, which lets you fetch the content of the paste. By default, we don't return that, since it could be large and you don't need it for some use cases (like showing a list of pastes).

There are at least three ways badges could return awards:

Attachments: We could add an "awards" attachment. However, this runs into trouble because attachments don't have a standard mechanism for limits/pages, so we'd be forced to return a million rows if a badge had been awarded to a million users. This isn't great.

Separate Method: We could implement something like to query for badge awards separately. This would work fine, but it's kind of clunky and awkward, and not clearly valuable on its own.

Separate Infrastructure: T5873 discusses possibly introducing new edge/relationship-oriented infrastructure for automatically constructing endpoints that query this type of data. This could potentially cover subscribers, awards, and other kinds of "potentially infinitely many" relationships.

None of these ways are clearly the right way, and we don't actually need this capability, so my recommendation for now is to simply not implement anything. We don't have enough information to choose the best approach and don't need to choose one, so we're best off just delaying the choice until later when we have more information.

(We don't really need these endpoints right now either, but the way forward for them is clear, and they're straightforward to implement, so they make sense to get through before unprototyping.)

This revision was automatically updated to reflect the committed changes.