#musicbrainz-devel

Just null the ID field by default then and it should work

reosarevok: you generally store lists in the opposite direction

list elements point to the thing that holds the list, not the thing that holds the list pointing to elements

but if we do flip that round, we can use NULL to model unknown

So yeah, please make sure you don't break [none] to add this :)

(I'm yet to see one release that needs it, although I know some exist - I'm not sure it is really worth the extra complexity but if people really want it)

I have one, though it's buried right now.

Well, yes, I'm certainly not doubting they exist, and I agree it would be better to be able to store it. It's just that adding several tables for it when the most common situation by far will be that they'll map 1:1 to releases as they do now seems weird

(adding extra joins to every single release for the benefit of a few)

some is a list of 0 or more actual barcodes. unknown is not none and count(some) = 0.

(woops, responding to random old backscroll lines)

But I guess it's at least more consistent than "store barcode if there's one, point to list if not"

reosarevok: yeah, I'm not keen on even more joins :(

make views then

I haven't got a clue how to do that

create view name as select ...

that's it

I don't know how to do the select

you know how to do a select with a join :)

yes, but I don't know how to select only one barcode

I don't want two rows for a single release just because some stupid release has two

why do you want to select only one barcode?

the array_agg

then*

On the musicbrainz-server VM the "musicbrainz_test" db doesn't exist. Is there a quick script somewhere to create it? With the musicbrainz user I can't create a DB and role "root" doesn't exist either.

JonnyJD: script/create_test_db.sh

it's in HACKING

hmm, actually, it isn't

tut

No, it isn't

It probably should be in "HACKING" though.

i'm adding it now

ocharles: why not just one table, (release.id, barcode), for which barcode contains either null, '' or a barcode? + a trigger like "if barcode is null, instead of new insert, update that"?

reosarevok: that doesn't set you store multiple barcodes

oh wait, a separate table, sorry

ocharles: it does if release.id isn't a key

yes, you can do that, but now you have to write triggers to enforce integrity

It's still lots of stuff for little gain, but if we want the little gain

when you could just model it to express the constraints you want

make barcode an array type in the database :)

I guess if I say "since barcodes hopefully don't have commas in them, enter them as comma-separated values" in the barcode column I'll get slapped, right? :p

warp: that is an option

reosarevok: postgresql has proper array types for lists of things.

with a GIN you can index that too

NULL is unknown, empty list is no barcode aka none, items in the list are barcodes.

warp: oh, ok :) (that also wasn't in my introductory course :) )

If that's doable, it sounds sensible

GIN?

that does however, make it difficult to enforce that barcodes form a set, not a list

As in, unordered?

and no duplicates

ocharles: make a report?

I mean, how many cases you expect

Of duplicate barcodes

A no-duplicates trigger is easy, though.

Or that

why do people insist on doing more work than necessary?

I mean, you'll need it anyway for merges

no, for merges you will need to de-duplicate

that is different from having a constraint

I don't see how an "on insert, don't insert anything if it's already there" trigger is unnecessary work.

Leftmost: I definitely don't want a trigger doing that

have fun with the barcodez. I'm going into the world for lunch and whatnot.

triggers that silently make queries do things different than what I ask is a world of pain

Fair enough.

Though isn't that what the no-dupes collection subscription trigger does?

heh

which one?

replace_old_sub_on_add? yes, I suppose it is

Someone recommends creating a unique index over the array to enforce uniqueness. Sounds like a horrible hack even if it works, though

I don't think a unique index on the array enforces that values in the array are unique

Dunno, I said "even if it works" :)

hmm

hm, are the links on https://musicbrainz.org/doc/Style supposed to go to wiki.mb and 10.1.1.102 ?

I guess if I say "add a second column for additional barcodes and leave the first one on the table as-is" I'll get shouted at, right? :p

(with that second column pointing to a second table or whatever)

Mineo: no

(but I guess you knew :p)

I guess we could do the multiple tables thing and *then* a view with arrays though?

I was unsure if the troubles last night required the links to be changed :)

Mineo: ok, my actual answer is "sounds extremely unlikely" then :p

reosarevok: yes to both questions :)

reosarevok: the view with an array is what I was suggesting above

Hmm. I'm guessing Ian was right and I'm not going to finish this review by today.

The main problem I can see with views is that they make it more annoying to graphically document the useful ways to use the schema (as in, I have no idea how it could be done)

Sure, you could document the actual tables but if nobody ever is going to want to use them that way...

(do we have any documentation about our current views, btw?)

no

:(

Leftmost: I think release(id, barcode_set nullable, ...), barcode_set(id), and barcode (barcode_set, barcode) might be the way to go.

primary keys on barcode_set.id and barcode.barcode

Okay.

I'm making a note of that and trying to get a bit of sleep. I'll push the changes in a few hours.

Thanks for talking it out with me.

it's a tricky one

ocharles, can you look at wtf is going on with the links Mineo mentioned?

is it urgent or can I have lunch first?

have lunch

:)

ok, will look after :)

Mineo, reosarevok: oh, bah - that was me "fixing" the wiki docs while internal DNS was broken

let me just fix that

Ok, should be better now

Seems to still point to the wiki?

Doesn't seem so

there might be a cache server side

i believe it'll fix itself in an hour

Ok

We'll see

:)

yea, I think that's easiest

ocharles has changed the topic to: 🌅 SUNRISE week | http://musicbrainz.org/#devel | note about meeting time in the US: http://bit.ly/Ym40ql | Agenda: reviews, MBS-5933 (ocharles), mbs-2079 (nikki), code reviewing non-MBS projects (ocharles/warp), MBS-2411 (ocharles)

I hope you don't mind me shoving a schema change ticket in front of 2079, nikki :)

should fixes for (old) update scripts in admin/sql/updates go to master or beta? (I have one for 20130125)

JonnyJD: I consider update scripts to be things which run once on release. So in general I would say you need to add a new script.

JonnyJD: either way, pull requests should go to beta.

Well, I am running that update script now and it errors out. Not sure if later update scripts depend on this

why not just get a new dump? january is quite some time ago.

ocharles: actually I just want to know what we should do with that ticket. most of the comments (and probably most of the votes too) are for a feature we added, but technically we haven't fixed the thing that's asked for... but I'm sick to death of seeing that ticket, thinking "...didn't we already add that?" and then realising I've mistook it for something else yet again

so it's not really that important, just annoying :P

Well, I don't actually want new data and I really don't want to move the whole DB again because I would run out of space in the VM with a complete update

nikki: ok (:

nikki: hm, marked is "In Progress" without being assigned seems odd.

warp: yeah. the whole ticket is a mess. it got set to in progress when ollie was doing the relationship editor thing he started (which, note, is not what the ticket asked for either :P)

warp: Anyways, I fixed the script so it works and would like to submit that upstream if anybody is interested. I don't think it is that important that a new script needs to be created.

I'm thinking it might be better to just make a new ticket for original requested behaviour and close that one and tell people to go vote for the new ticket if they still want it

JonnyJD: ok, well just submit it as a pull request to beta like any other change.

so that we have some idea of how many people actually want that and how many were just like "gaaaah I can't link works for a release" (since solved by the relationship editor)

nikki: i'm fine with that

nikki: that sounds like a perfectly reasonable thing to do.

then maybe I should just do that now and take it out of the agenda :P

is there a known validator.nu "mirror"? http://validator.nu is offline and testing takes ages since it always waits for a timeout. (I did set an empty validator in DBDefs.pm for now)

JonnyJD: you can run your own

(assuming the source repositories are still online)