#metabrainz

I can't remember the last time one of our (ancient) deps broke due to a perl upgrade

[musicbrainz-server] yvanzo merged pull request #1984 (production…mbs-11446-trim-n): MBS-11446: Keep blank lines in annotation https://github.com/metabrainz/musicbrainz-serve...

bitmap: what about node, what to?

latest LTS?

there's a new LTS release in april, should probably go with that.

Ok

v16?

yes

let's do that

Perfect

does perl 5.32.x seem ok if all tests pass/deps compile?

+1

or I'm fine with 5.30.x if you prefer

bitmap: keep a perl version that we can have in our base image maybe? :P

Is 5.32 available from debian / ubuntu?

focal has 5.30

I doubt from the official repoos

lol repoos. stupid keyboard

focal (ubuntu 20.04 - latest LTS)

Then maybe let's do 5.30, unless there's something very special added in between

reosarevok: into the vm and into our images for production :)

I'm hoping there's a popular/well-supported apt repo we could use though

ok, that's a good argument for 5.30 then

so perl 5.30, node v16 it is

alright

Neat

perl 5.30 is in debian sid

anything else we should discuss from https://gist.github.com/mwiencek/8015985a5a9338... ?

We should see what has tickets and add the missing ones

do we want/expect to support cardinalities other than 0/1?

Maybe, but not higher than 255

Oh, postgres has no tinyint to begin with

Were you considering an ENUM or?

yeah. we could use a bit string if we only need a byte

smallint is two bytes

You suggested possibly wanting a third type (shown for editing but not display IIRC?) recently

So maybe we should play it safe

ratings/reviews for place? ^^

tripbrainz? :)

a byte would be 255

Oh, now I got it

Sorry, I was thinking of "a bit"

yvanzo: place, not area :)

bitmap: I think it's safe to say we won't have 255 cardinalities

I'm not sure/don't think PG has column types below 1 byte, at least

what is "root column to the link_type table" for?

(even boolean uses 1 byte last time I checked the docs)

yvanzo: like how link_attribute_type has a root column referring to the top-most type

we currently use a recursive query to calculate those

I can't imagine it's slow given the size oof the table, but having it stored is more convenient

oof

ooof

that's the eighth time I've oof'd today alone

oof

bitmap: ok, there is no ticket associated to it, right?

not as oof yet

do either of you want to claim any of these?

then the owner can make their own tickets :)

:D

ooof ;)

!recall oh no.

bitmap: should https://tickets.metabrainz.org/browse/MBS-5423 be closed?

MBS-5423: Finish "Log Statistics" work other than schema changes, merge, integrate

Or is that unrelated to drop statistics.log_statistic

that's related, so yes (unless we still have a planned use for this table)

Any example of visible cardinality from the website? You seem to be very at ease with it :)

yvanzo: we don't show all recordings of a work in the relationship editor when editing a work (or a release) because of cardinality

yvanzo: I don't think the actual number is visible except from the attribute doc page / admin forms

Oh, the number itself? Also from relationship type edits

but we use it to indicate if one side of a relationship has many or few relationships

personally I wish a work/UUID/edit *did* show all those

of a relationship or of a relationship type?

well they do if you add them there :D

one side of a relationship type, sorry

could be a separate lazy load tab?

CatQuest: that's something we were thinking about, yeah

using it to determine whether to use paging/lazy-loading rather than hiding it altogether

oh!

so 1 is many and 0 is few?

we were?

I didn't remember, but that doesn't sound bad :p

:o

yes, didn't you mention earlier that we did? :P

wait if ya's listening to me I have other ideas too!

..

< reosarevok> oof

he did ^

if I can remember :D

bitmap: last, edit_data_type_info is a current function, why replacing it with a script?

(or generating it with a script?)

that one wasn't clear, sorry

we never had a script to create the function on mirrors, I only added it to the prod DB

soo we should have it be created during the schema change. not that it's used anywhere

ok, thanks.

bitmap: can't edit your gist, should we link created tickets to it somehow, or do we just put them into the fix version?

I could create a google doc instead if that helps

I think I got it all but cardinality change, so I cannot take this one.

The cardinality change would probably currently only involve changing the type of the column, no?

let's just create tickets for each point.

(we can later decide to do more stuff with it, but)

bitmap: if you want, that might help

right. the cardinality one is just about saving a few measly bytes

ok. unpopular opinion. how hard would "dynamic attributes" be?

I mean: the cardinality itself seems to be underdocumented.

CatQuest: that already is in current schema.

yes reo jsut told me in a pm

Yeah, that doesn't need a schema change, just... time

i was so sure it was schema since it hadn't ben done :o

awww

honestly dynamic atributes and alt tracklists are the 2 most wanted tickets anyway for m

(relatedly, those big unfinished things are why this list is "a lot of small, easy changes, often backend and not very relevant to users but make stuff work better")

that and maybe merge vocal-tree into instruments

oohhh

(to some degree it is "let's show we can actually *finish* a schema change for once" :p )

making stuff work better is always a mega plus

espeically if it means the big unfinished thing will be easier to make later

loi

reosarevok: that and react migration.

it's on overtime for sure

yvanzo: sure :)

yep was gonna say

that damn react

:P

yvanzo: reosarevok: https://docs.google.com/document/d/1gwZlu52ukLT...

CatQuest: probably the most user-wanted change this year is recording year, but that's already in on the main site

how is the ETA on react anyway? andy % on how much is left?

CatQuest: damn helpful for the future of MB :)

Andy Percent sounds like a DJ