#metabrainz

The developers manually fetch translations from Transifex before making a release.

Leftmost: but dimensions aren't strings :(

Mineo: https://github.com/opatel99/picard/commit/69999...

All those changes in the .pot file has me worried I did something wrong.

opatel99: it's mostly just line number changes, other than the new stuff you added. That's normal

looks like someone added a new string before you but forgot to regenerate the pot file :)

For "Key"

Oh so that shifted everything...

nah, the line number shifts are just do to various other changes since the last time the file was regenerated. Don't worry about them

LordSputnik, they're not integers either. They're complex data types that libraries store in a semi-standardized format.

Which libraries and what standard?

The standard I know about is apparently from the Anglo-American Cataloguing Rules, Second Edition used in the US, Canada and UK, superseded in 2010 by a similar format from the Resource Description and Access standard, which is in use in the US. (Not sure about elsewhere.)

OK, but surely storing as a string opens up all kinds of problems?

And takes up more space

it would be nice to have machine-readable dimensions; would it be possible to parse/generate the format in question, or is it too variable?

And is harder for sorting

I'm not suggesting we make full use of that format, just that we allow leeway in how things are entered. For one thing, the semantics of our storage is unclear. We don't specify units or a standard means for determining number of pages, which both AACR2 and RDA do.

We specify units

mm for the dimensions and g for the weight

and no matter our storage units, someone should be able to select display units

Okay. Well, libraries typically measure books in cm but sometimes in mm.

Unless we get a ton of complaints I don't really want to change storing whole numbers as integers :P

Pagination is also something libraries care about.

That'd be a separate field anyhow, I guess.

I'm temporarily convinced while I do more research. :-P

The Book (disambiguation: 234.56 mm width edition)

At greater precisions than mm, the width of the book depends on the amount of pressure you apply :P

Leftmost: so I'm thinking about OAuth with MB

Do we want to get back the user's username or email address for performing lookups in our own editor table?

(or both?)

I guess an ID would be better

might be nice to have enough precision to store reasonable representations of up to maybe 1/16 inch in mm, which you could probably do with an extra 2 decimal places or so.

For now, I suggest we stick with what we have until MB actually has an SSO plan.

Gentlecat is doing the same thing for CB

(afaik)

what am I doing? :)

Gentlecat: the OAuth stuff we were talking about the other day, when you were asking about whether we decided upon anything at the summit

We've got a _lot_ of churn in our code right now and I'd like to hit the target I'm looking at (integrating the reworked schema and data package into -site and -ws) and move it after.

I don't remember how email address is returned from oauth endpoint

if it's always verified or not, etc.

opatel99: don't bother with potfile in Picard, make your PR marking strings to be translated as usual. I'll regenerate and commit the potfile at some point, it will be retrieved by transifex few hours later and strings to be translated will be available for translation

Leftmost: OK, good point, let's leave users alone for now

besides, there's an issue of keeping everything in sync, which is annoying

zas: Oops... Too late for the current, but will keep that in mind for next time

On the plus side, I'm pretty satisfied with the schema diagram we have right now and I think we're in a position to do a soft freeze on it once we get it implemented, if that sounds reasonable.

I will also resync translations in Picard sources, before a release or on regular basis if, as usual, we don't release often enough.

Leftmost: I'm going to change password to a CHAR(64)

So no need to worry about it in the future. zas

Leftmost: Oh, no, CHAR(60) :P

Oh, good call.

Haha, I don't know how editions got a gender ID :P

Yes. Pot file update has to be done in master branch rather than in pull requests. Else we'll get unneeded conflicts.

Should I delete the branch and resubmit, or is that ok?

Gentlecat: MB doesn’t even store unverified addresses. :)

well, shows how much I know about it :)

zas:

opatel99: in your string it is preferable when possible to keep the same accel key here I would keep the & before the P

LordSputnik, can we do away with using Handlebars templates stored in the database somehow?

Leftmost: Whats the matter with that?

And you can just drop the Picard.pot changes

We need some way of templating the relationship string, and Handlebars is pretty lightweight

Fair enough. It just seems... dirty to me.

If we stored something like "_s_ authored _t_" instead, it's just a different templating format

I guess we can start to think about a Picard release after the GCI

Leftmost: At least with the new schema the handlebars parameters become much cleaner

anniezhou301 closed pull request "Login and Register pages converted into react.js" without merge (https://github.com/bookbrainz/bookbrainz-site/p...)

LordSputnik pushed 1 commits to bookbrainz-sql: https://github.com/bookbrainz/bookbrainz-sql/co...

Leftmost: should we shut down Bookzombie?

Leo_Verto: ^ same question

D:

Because it's too spammy?

Maybe we need a #metabrainz-botspam channel.

Leo_Verto: partly, yeah, but also because we could just use gitter to notify each other about commits

“hopefully Christina will allows us” -s

darwin: you might have an opinion on this: Is there any advantage to using NULL to represent an empty string in a TEXT field in postgres to just storing an empty string?

Um

Am I using Gitter wrong? There's only Freso and me in the metabrainz channel and the only message is from me and 2 months old

LordSputnik: Semantically, NULL means “unknown value”.

Empty string means “known empty”.

Also I thought keeping all communication transparent and in one place was one of the recent goals

chirlu`: I know that

E.g. in MB, barcode = NULL means we don’t know, barcode = "" means someone ticked the “this release has no barcode” checkbox.

LordSputnik: Well, then, the answer is “Yes, it is advantageous if the value is unknown rather than empty”.

Leo_Verto: true, but bot notifications aren't necessarily communication we want to keep around

chirlu`: I'm asking from a storage/performance point of view

I'd guess that NULL is faster because it is stored in-table, while TEXT is stored externally, right?

chirlu`: you're right, that's probably a better point of view

Mhm, we could work around this by either having Bookzombie prefix messages with [off] or BrainzBot ignoring all it's messages, but I can see your point

leftmostcat pushed 1 commits to bookbrainz-sql: https://github.com/bookbrainz/bookbrainz-sql/co...

LordSputnik, ^ look okay to you?

Either way, I say !m must stay!

Leftmost: Just a sec, also - do you think we need to differentiate between "unknown bio" and "empty bio"? If not, I'll make bio NOT NULL

My stance is that commit bots and build bots are useful, but in a high-traffic channel can interfere with discussions (particularly for users new to IRC, which may be relevant during GCI.

Leo_Verto: !m is BrainzBot though!

Is bio not already NOT NULL?

Nope

I'm going through checking NULLs atm

Oh, wait. Why should it be NOT NULL?

Oh, I guess that's solved then :P

Leftmost: because I don't think there's a need to distinguish between "unknown bio" and "empty bio"

Sure, but why store "empty" at all, in that case?

Leftmost: well, we have to have the field, unless we have a editor_bio table

(it's currently at editor.bio)

I'm just very confused as to why we'd want to store '' instead of NULL, rather than the other way around.

Leftmost: because NULL is meaningless here :P

I'd argue that '' is meaningless here. :-P

If the editor fills out their bio, it's a non-empty string. If the editor deletes the filled out bio, it's an empty string (''). If the editor leaves it blank, it's NULL. I don't think we need to distinguish between the latter two

LordSputnik: I don't know the answer in postgres, in mysql it barely matters.

I dunno. It just seems an odd way to store it. To me, NOT NULL hints that we really want something in that field, but I dunno. I agree we don't need to distinguish, but I'd vote for instead: unset = NULL, set = 'blah', deleted = NULL.

If that sounds wrong to you, go ahead and go NOT NULL.

in my world, things which always should be set are NOT NULL

things which may not always be set may be NULLable, especially if NULL has a different meaning from "0" or "empty string"

but NULL complicates queries and does not generally save space on disk...

Yeah, I tend to see NOT NULL as indicating things should always be set.

You should also consider that the ternary logic is often unintuitive and will lead to bugs. E.g., most people would think that WHERE editor.bio LIKE '%foo%' OR NOT (editor.bio LIKE '%foo%') is going to match every row.

chirlu`: ("NULL complicates queries")

chirlu`, in the instance where it's NULLable?

Yes.

Fair enough.

Example for a bug that bit MB: https://musicbrainz.org/edit/29424653

The name changed from '' meaning no name to NULL meaning no name.

LordSputnik pushed 1 commits to bookbrainz-sql: https://github.com/bookbrainz/bookbrainz-sql/co...

Leftmost: I'm wondering if we can choose a better field name than "is_primary"/"primary" for that alis field

is_primary_for_locale? :-P

MB: primary_for_locale