Closed ham3r closed 3 years ago
Oparcie logiki o sortowanie po updatedAt
może sprawić, że np. zgubisz zamówienia. Nie gwarantujemy, że zamówienia będą pojawiać się idealnie wg kolejności pola updatedAt
.
Potencjalna sytuacja obrazująca problem:
Dlatego też zalecamy korzystanie z dziennika zdarzeń - wtedy masz pewność, że nie pominiesz żadnego zamówienia.
Rozumiem. A co jeżeli pobieramy większą liczbę zamówień (np. milion), co może mieć bezpośrednio wpływ na liczbę requestów?
Jeżeli rzeczywiście istnieje taki problem, to czy widzicie Państwo jakieś przeciwwskazania, aby podejść do sprawy hybrydowo, tj. zaciągać dziennik zdarzeń i zamówienia z /order/checkout-forms
, a następnie różnicę uzupełnić pojedynczo przez /order/checkout-forms/:id
?
Takie podejście, moim zdaniem ,wygląda sensownie i pozwala wyłapać braki w zamówieniach.
@ham3r być może będzie to dobre rozwiązanie, tutaj rozbija się to już o szczegóły implementacji.
W tym wątku nie pojawiła się żadna nowa odpowiedź w ciągu 30 dni. Dlatego automatycznie oznaczamy go jako przeterminowany. Jeśli w ciągu 7 dni nie pojawi się żadna odpowiedź, zamkniemy ten wątek. Dziękujemy za zaangażowanie w dyskusję.
Dzień dobry,
piszą Państwo, że zalecaną metodą pobierania najnowszych zamówień jest użycie dziennika zdarzeń. https://developer.allegro.pl/orders/#lista-zam%c3%b3wie%c5%84
Czy uwaga o polu
boughtAt
jest aktualna, jeżeli dla zasobu/order/checkout-forms
jest możliwe sortowanie po poluupdatedAt
?Czy pobranie zamówień przez...
from
), a potem pojedynczo przez/order/checkout-forms/:id
orazupdatedAt.gte
i sortowaniaupdatedAt
)...jest odwzorowane 1:1?
A może jednak są pewne niuanse, może czegoś brakuje, może coś jest pomijane, przez co korzystanie z
/order/checkout-forms
jest niewłaściwe?Pozdrawiam!