Custom Query (2152 matches)
Results (274 - 276 of 2152)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#322 | fixed | Client interface for Notification Service | dread | dread |
Description |
Use cases
Design
Routing detailRouting key format: "OBJ_TYPE" (NB tags should be identified by their name, not ID) Example routing keys
Example queue bindings that clients may use:
VersioningSince message payloads will be tied into the REST Entities, it makes sense to join up with the REST versioning. This could be achieved by providing new exchanges called 'ckan-1.1' perhaps? Documentation
|
|||
#323 | fixed | Notification message | dread | dread |
Description |
Which events to notify onListed by domain object, these are the notification message 'change types' that will be sent:
Also it is clear that it could be useful to know when db-wide maintenance is carried out:
Ignored domain objectsThese parts of the domain model will not carry notifications as no use case has been identified for them:
Message formatA notification message's header contains the routing key, identifying the object type. The client is probably interested in the object (all use cases so far), so it makes sense to send the object in the payload. This should be the JSON-encoded dictionary exactly as provided for the object's REST Entity. For the 'db' notifications there shall be no payload. |
|||
#324 | fixed | Search indexing using notifications | dread | dread |
Description |
Currently search indexing is triggered directly using a Postgresql db callback. Now take advantage of the Notification system to register interest in all package changes and db changes to trigger this instead. The indexing shall run in a separate shell/process, managed by supervisord. |