Adding a 'modified' tag to a 'calevents_list' API request

We have already announced it 2017, that we will end the development and support of EQdkp Plus. As we are not able anymore to effort the required time to maintain EQdkp Plus, and we didn't received any help, we have decided to end the complete project EQdkp Plus. Therefore, there will be one last release of EQdkp Plus.

All relevant information are already transferred to GitHub. Additional scripts, documentation and the Source Code is available at our GitHub Repository. The project tools like board, wiki etc. will be removed in ca. 2-3 months.

We want to thank you for your journey with EQdkp Plus over all these years, and wish you a lot of successful raids.

The EQdkp Plus Team
  • Hi,


    I would appreciate it if there would be a 'modified' and 'modified_timestamp tag to the API response of a calevents_list or calevents_details&eventid=<id>.


    Modified should then be updated as soon as a status change is made in:

    • 'status<id>' in 'raidstatus' (e.g. switching from registered to confirmed)
    • start/end date
    • title
    • note
    • ???

    Since there is no websocket connection to the calendear events nor an easy way to check modifications, it is currently quite cumbersome to detect changed data for an external script.


    Best regards,

    Operator

  • There is an easy way to detect changes: hash the content and save the hash. If the hash has changed, then the containing data was changed.


    As it requires us to save a lot of data (e.g. when the resource has last fetched the API data etc.), that's something the client can make a lot easier with the hashing approach.

    Viele Grüße,
    GodMod


    Bitte sendet mir keine unaufgeforderten Support-PNs. | Please don't send me unwanted support-PMs.
    Du willst dich bei mir bedanken: | You want to thank me:

    amazon_wishlist.jpg paypal_logo.jpg

  • GodMod

    Added the Label Not planned
  • Hashing is a good approach. However, this would require a hash list to be maintained on the client side for each eventid, which might need to be freed from old, expired posts. If this is not done, the list will become very long. And in my opinion it is more complex to maintain than the following approach.


    Quote

    when the resource has last fetched the API data

    is not relevant, because this kind of 'modified' was not meant. It is irrelevant when the API was last queried, it's just the modification on the calendar data page.

    For this another column in calendar_events in the SQL database would be my approach (e.g. timestamp_modified) and this will be updated by SQL Update as soon as a modification is made to the entry. Since SQL Update sequences have already been executed, this would not lead to an excessive load or data transport, since the necessary data for the update process has already been requested (registration, deregistration, reserve slot, etc.).

  • But when adding the timestamp_modified, you need also to store the timestamp_modified for each event ID on the client to check if there has been a modification made. So it's the same with hashes.

    Viele Grüße,
    GodMod


    Bitte sendet mir keine unaufgeforderten Support-PNs. | Please don't send me unwanted support-PMs.
    Du willst dich bei mir bedanken: | You want to thank me:

    amazon_wishlist.jpg paypal_logo.jpg

  • But when adding the timestamp_modified, you need also to store the timestamp_modified for each event ID on the client to check if there has been a modification made. So it's the same with hashes.

    True!


    Never wright an answer on the way home without having diner so far :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!