Closed italovalcy closed 1 year ago
Great catch Italo. From what I can tell historically, this settable indexed id
was probably to act like an unique (meaningful) name.
I think we could also not expose it to be set, fewer validations and code to maintain as well. If we end up not allowing it to be set, we can also end up in cases with a random ID and empty description
(if users don't fill out), which is OK as well, but in the front-end having a tool tip or something encouraging to always add something in the description might be useful (I'm thinking of cases where a network operator for instance create multiple non overlapping MWs, all relatively similar but without description and then don't remember which one was for what purpose).
@Ktmi if you could add this one in your radar and assess/propose a solution and fix it, thanks.
This sounds like its going to need an API version bump. We can combine this with removing the timezone requirement for datetime.
This sounds like its going to need an API version bump. We can combine this with removing the timezone requirement for datetime.
Indeed, David. Regarding removing the timezone, ideally, let's also ship a migration script with readme instructions to update the values of existing documents accordingly. Here's a related script example that we've shipped before.
Thanks.
Closed with #78
Hi,
When adding a MW with duplicated ID, Kytos server returns a 500. error (
Error 500 when creating a MW with same id of existing one
):Should we accept ID as the input attribute? It looks like ID would be an internal field - auto-generated (as it currently is).
If we accept ID as an input parameter, it would be nice to have some validations and return a 4xx error instead of 500. But once again, I don't think we should allow ID to be received from the user.