MBS-12839: Allow searching for edits by kind of edit type
2023-01-19 01945, 2023
reosarevok
The description our template currently tries to find from the wiki (but AFAICT only exists for https://musicbrainz.org/doc/Edit_Types/314 because I added it last year to test)
MBS-12840: Revert lumping of historic edits into reused names
2023-01-19 01910, 2023
yvanzo
It would probably be better to help with keeping this documentation synced but there is nothing we cannot do about the current documentation from the wiki atm.
2023-01-19 01944, 2023
reosarevok
Well, I think we have pretty much no docs, so I was thinking we could decide to use hardcoded docs first, then start actually writing some :D
2023-01-19 01959, 2023
reosarevok
We can also start on the wiki, but hardcoding from the start makes them translatable, which is nice I guess
That's not even a link to the *appropriate* edit type page, just the generic list
2023-01-19 01941, 2023
yvanzo
Right, there is no validation for this kind of transclusion I guess?
2023-01-19 01958, 2023
reosarevok
Not unless you add the edit to the transclusion table, it's the same as with /doc
2023-01-19 01905, 2023
reosarevok
(I did that with the one I documented)
2023-01-19 01920, 2023
reosarevok
Guess I'll add a ticket to link to the specific edit type from the sidebar, that should be a trivial fix
2023-01-19 01928, 2023
alastairp
reosarevok: I'm here now too, tell me when you've finished up with your thing
2023-01-19 01935, 2023
yvanzo
If there is no edit type using it, it might be safer to shut it down then.
2023-01-19 01901, 2023
reosarevok
I'll also enter a ticket then to move from wiki to code for descriptions
2023-01-19 01905, 2023
jasje_ joined the channel
2023-01-19 01911, 2023
reosarevok
alastairp: as soon as I've entered the tickets I'm all yours
2023-01-19 01915, 2023
yvanzo
👍
2023-01-19 01917, 2023
reosarevok
Well, mostly.
2023-01-19 01923, 2023
yvanzo
To code or to the database.
2023-01-19 01958, 2023
reosarevok
Yeah. I'm thinking code for now because we don't have an edit type table
2023-01-19 01959, 2023
yvanzo
(Probably better to the code indeed, dunno)
2023-01-19 01908, 2023
reosarevok
But that's a bit puzzling, so eventually we might want to change that
2023-01-19 01917, 2023
yvanzo
We will have a schema change this year ;)
2023-01-19 01929, 2023
reosarevok
You literally told me you wanted no big changes :D
2023-01-19 01938, 2023
reosarevok
We'll see :) Something to talk at a team meeting too
2023-01-19 01945, 2023
yvanzo
It’s not big as it doesn’t affect replication.
2023-01-19 01917, 2023
yvanzo
(Or maybe it does but just by creating a new dispensable table.)
2023-01-19 01926, 2023
reosarevok
I mean, it would mean rewriting how we get and use edit data, I guess? Unless it's just kind of a copy of what's already in the code. But certainly doable
so there's a yaml specification which includes things like "this is an endpoint", "these are the parameters", "this is the output"
2023-01-19 01908, 2023
alastairp
and it seems like much of this could be autogenerated from a simpler doc, however I'm not sure if it could be autogenerated from musicbrainz-server code
2023-01-19 01947, 2023
reosarevok
Well, we do have a lot of tests at the very least which are literally "URL, expected response"
2023-01-19 01931, 2023
alastairp
it looks like there's also a templating/reference syntax (in the editor example there's a bunch of `$ref: '#/components/schemas/Pet'`
So it's kinda there, but for example it doesn't have anything that specifically says the first of those is a search, second a collection browse, third a normal browse. Fourth being a lookup is listed at least
2023-01-19 01919, 2023
alastairp
that definitely seems like it might be possible to inspect this and generate the structure. Although I guess it has no textual descriptions in it
2023-01-19 01929, 2023
alastairp
would it make sense to add textual descriptions directly to the perl code?
2023-01-19 01905, 2023
reosarevok
What should the descriptions look like?
2023-01-19 01923, 2023
reosarevok
Stuff like " description: Update an existent pet in the store" in the example?
Yes, I agree that pet is very much a basic thing for MB
2023-01-19 01951, 2023
lucifer
does that mean AnimalBrainz is on the cards as well?
2023-01-19 01900, 2023
alastairp
well, we already have a monkey
2023-01-19 01907, 2023
lucifer
given that AB is being retired we could also reuse the acronym.
2023-01-19 01929, 2023
alastairp
right. I've not got into parameter definitions in openapi yet, I wouldn't be surprised if it can properly handle it. but again it's a question of deciding if it's easier to auto-generate it from the code, or just carefully maintain the specification manually
2023-01-19 01933, 2023
reosarevok
I'm guessing the best option long term might be to have a yaml or json file with the definitions, then have code to make the required $ws_defs based on that
2023-01-19 01902, 2023
reosarevok
So have a specification, and use *that* to generate the code
2023-01-19 01914, 2023
reosarevok
But not sure if that'd work well
2023-01-19 01937, 2023
alastairp
oh yeah
2023-01-19 01927, 2023
lucifer
alastairp: lmk when you have a moment to talk about time zones.
2023-01-19 01944, 2023
vibhoo_24 joined the channel
2023-01-19 01912, 2023
reosarevok
Also, yes, I do know the API docs are mediocre
2023-01-19 01940, 2023
reosarevok
I was aiming for something kinda like this swagger thing but it's hard to do that decently on a wiki (I'm sure it could still be a lot better than what I ended up with, mind)
2023-01-19 01915, 2023
reosarevok
So do I understand correctly some of our APIs are already documented in Swagger? Where do they live?
2023-01-19 01920, 2023
reosarevok
I would like to take a quick look to what can be done
2023-01-19 01919, 2023
reosarevok
s/to/at/
2023-01-19 01933, 2023
reosarevok
(and to understand where we'd have the finished docs)
> To describe the parameter contents, you can use either the schema or content keyword. They are mutually exclusive and used in different scenarios. In most cases, you would use schema. It lets you describe primitive values, as well as simple arrays and objects serialized into a string.
2023-01-19 01905, 2023
lucifer
technically, its right but from the user perspective weird.
2023-01-19 01928, 2023
lucifer
(see the timestamp of the 3rd, 4th, 5th listen)
2023-01-19 01921, 2023
alastairp
lucifer: you'll have to explain to me why the 4th has a timestamp of 2pm
2023-01-19 01951, 2023
lucifer
alastairp: because i submitted it in IST :), whereas the others in NZST.
2023-01-19 01955, 2023
lucifer
and when listens are sorted by converting the times to utc, this is how it lines up.
2023-01-19 01942, 2023
alastairp
can you please give me a list of the timestamps as submitted for all 5 of them?
2023-01-19 01902, 2023
alastairp
my initial response to this is "if the timezone changes, then of course the data will be different"
