All those changes in the .pot file has me worried I did something wrong.
2015-12-09 34348, 2015
kepstin
opatel99: it's mostly just line number changes, other than the new stuff you added. That's normal
2015-12-09 34319, 2015
kepstin
looks like someone added a new string before you but forgot to regenerate the pot file :)
2015-12-09 34331, 2015
kepstin
For "Key"
2015-12-09 34307, 2015
opatel99
Oh so that shifted everything...
2015-12-09 34358, 2015
kepstin
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
2015-12-09 34321, 2015
Leftmost
LordSputnik, they're not integers either. They're complex data types that libraries store in a semi-standardized format.
2015-12-09 34321, 2015
LordSputnik
Which libraries and what standard?
2015-12-09 34314, 2015
Leftmost
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.)
2015-12-09 34308, 2015
kepstin should go to his library and check out a copy of this book ;)
2015-12-09 34316, 2015
LordSputnik
OK, but surely storing as a string opens up all kinds of problems?
2015-12-09 34300, 2015
LordSputnik
And takes up more space
2015-12-09 34305, 2015
kepstin
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?
2015-12-09 34306, 2015
LordSputnik
And is harder for sorting
2015-12-09 34315, 2015
Leftmost
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.
2015-12-09 34331, 2015
LordSputnik
We specify units
2015-12-09 34358, 2015
LordSputnik
mm for the dimensions and g for the weight
2015-12-09 34307, 2015
kepstin
and no matter our storage units, someone should be able to select display units
2015-12-09 34356, 2015
Leftmost
Okay. Well, libraries typically measure books in cm but sometimes in mm.
2015-12-09 34341, 2015
LordSputnik
Unless we get a ton of complaints I don't really want to change storing whole numbers as integers :P
2015-12-09 34344, 2015
Leftmost
Pagination is also something libraries care about.
2015-12-09 34330, 2015
Leftmost
That'd be a separate field anyhow, I guess.
2015-12-09 34353, 2015
Leftmost
I'm temporarily convinced while I do more research. :-P
2015-12-09 34356, 2015
kepstin suspects that most librarians don't go measuring books with micrometers, so mm is probably sufficient resolution... but it wouldn't hurt to have a little more precision just in case ;)
2015-12-09 34347, 2015
chirlu`
The Book (disambiguation: 234.56 mm width edition)
2015-12-09 34359, 2015
LordSputnik
At greater precisions than mm, the width of the book depends on the amount of pressure you apply :P
2015-12-09 34322, 2015
LordSputnik
Leftmost: so I'm thinking about OAuth with MB
2015-12-09 34341, 2015
LordSputnik
Do we want to get back the user's username or email address for performing lookups in our own editor table?
2015-12-09 34357, 2015
LordSputnik
(or both?)
2015-12-09 34316, 2015
LordSputnik
I guess an ID would be better
2015-12-09 34331, 2015
kepstin
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.
2015-12-09 34332, 2015
Leftmost
For now, I suggest we stick with what we have until MB actually has an SSO plan.
2015-12-09 34330, 2015
LordSputnik
Leftmost: We do have one in the short term
2015-12-09 34336, 2015
LordSputnik
Gentlecat is doing the same thing for CB
2015-12-09 34341, 2015
LordSputnik
(afaik)
2015-12-09 34359, 2015
Gentlecat
what am I doing? :)
2015-12-09 34316, 2015
LordSputnik
Gentlecat: the OAuth stuff we were talking about the other day, when you were asking about whether we decided upon anything at the summit
2015-12-09 34324, 2015
Leftmost
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.
2015-12-09 34345, 2015
Gentlecat
I don't remember how email address is returned from oauth endpoint
2015-12-09 34312, 2015
Gentlecat
if it's always verified or not, etc.
2015-12-09 34323, 2015
zas
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
2015-12-09 34325, 2015
LordSputnik
Leftmost: OK, good point, let's leave users alone for now
2015-12-09 34350, 2015
Gentlecat
besides, there's an issue of keeping everything in sync, which is annoying
2015-12-09 34307, 2015
opatel99
zas: Oops... Too late for the current, but will keep that in mind for next time
2015-12-09 34359, 2015
Leftmost
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.
2015-12-09 34307, 2015
zas
I will also resync translations in Picard sources, before a release or on regular basis if, as usual, we don't release often enough.
2015-12-09 34320, 2015
LordSputnik
Leftmost: I'm going to change password to a CHAR(64)
2015-12-09 34326, 2015
opatel99
So no need to worry about it in the future. zas
2015-12-09 34358, 2015
Tecfan_ joined the channel
2015-12-09 34337, 2015
LordSputnik
Leftmost: Oh, no, CHAR(60) :P
2015-12-09 34342, 2015
Leftmost
Oh, good call.
2015-12-09 34329, 2015
LordSputnik
Haha, I don't know how editions got a gender ID :P
2015-12-09 34323, 2015
zas
Yes. Pot file update has to be done in master branch rather than in pull requests. Else we'll get unneeded conflicts.
2015-12-09 34341, 2015
opatel99
Should I delete the branch and resubmit, or is that ok?
2015-12-09 34306, 2015
chirlu`
Gentlecat: MB doesn’t even store unverified addresses. :)
2015-12-09 34327, 2015
beqn_ joined the channel
2015-12-09 34330, 2015
D4RK-PH0ENiX has quit
2015-12-09 34336, 2015
alastairp joined the channel
2015-12-09 34345, 2015
Gentlecat
well, shows how much I know about it :)
2015-12-09 34358, 2015
opatel99
zas:
2015-12-09 34311, 2015
opatel99 has quit
2015-12-09 34339, 2015
zas
opatel99: in your string it is preferable when possible to keep the same accel key here I would keep the & before the P
2015-12-09 34351, 2015
Leftmost
LordSputnik, can we do away with using Handlebars templates stored in the database somehow?
2015-12-09 34315, 2015
LordSputnik
Leftmost: Whats the matter with that?
2015-12-09 34328, 2015
zas
And you can just drop the Picard.pot changes
2015-12-09 34340, 2015
LordSputnik
We need some way of templating the relationship string, and Handlebars is pretty lightweight
2015-12-09 34350, 2015
Leftmost
Fair enough. It just seems... dirty to me.
2015-12-09 34344, 2015
LordSputnik
If we stored something like "_s_ authored _t_" instead, it's just a different templating format
2015-12-09 34346, 2015
zas
I guess we can start to think about a Picard release after the GCI
2015-12-09 34304, 2015
LordSputnik
Leftmost: At least with the new schema the handlebars parameters become much cleaner
chirlu` finds a mistake in the business-relations blog post.
2015-12-09 34323, 2015
LordSputnik
Leo_Verto: partly, yeah, but also because we could just use gitter to notify each other about commits
2015-12-09 34340, 2015
chirlu`
“hopefully Christina will allows us” -s
2015-12-09 34320, 2015
LordSputnik
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?
2015-12-09 34325, 2015
Leo_Verto
Um
2015-12-09 34333, 2015
D4RK-PH0ENiX joined the channel
2015-12-09 34308, 2015
Leo_Verto
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
2015-12-09 34342, 2015
chirlu`
LordSputnik: Semantically, NULL means “unknown value”.
2015-12-09 34350, 2015
chirlu`
Empty string means “known empty”.
2015-12-09 34350, 2015
Leo_Verto
Also I thought keeping all communication transparent and in one place was one of the recent goals
2015-12-09 34359, 2015
LordSputnik
chirlu`: I know that
2015-12-09 34301, 2015
chirlu`
E.g. in MB, barcode = NULL means we don’t know, barcode = "" means someone ticked the “this release has no barcode” checkbox.
2015-12-09 34300, 2015
chirlu`
LordSputnik: Well, then, the answer is “Yes, it is advantageous if the value is unknown rather than empty”.
2015-12-09 34301, 2015
LordSputnik
Leo_Verto: true, but bot notifications aren't necessarily communication we want to keep around
2015-12-09 34326, 2015
LordSputnik
chirlu`: I'm asking from a storage/performance point of view
2015-12-09 34344, 2015
LordSputnik
I'd guess that NULL is faster because it is stored in-table, while TEXT is stored externally, right?
2015-12-09 34357, 2015
chirlu` is answering from a “Premature optimization is the root of all evil” point of view.
2015-12-09 34342, 2015
LordSputnik
chirlu`: you're right, that's probably a better point of view
2015-12-09 34344, 2015
Leo_Verto
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
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
2015-12-09 34344, 2015
Leftmost
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.
2015-12-09 34348, 2015
LordSputnik
Leo_Verto: !m is BrainzBot though!
2015-12-09 34302, 2015
Leftmost
Is bio not already NOT NULL?
2015-12-09 34306, 2015
LordSputnik
Nope
2015-12-09 34315, 2015
LordSputnik
I'm going through checking NULLs atm
2015-12-09 34317, 2015
Leftmost
Oh, wait. Why should it be NOT NULL?
2015-12-09 34318, 2015
Leo_Verto
Oh, I guess that's solved then :P
2015-12-09 34344, 2015
LordSputnik
Leftmost: because I don't think there's a need to distinguish between "unknown bio" and "empty bio"
2015-12-09 34317, 2015
Leftmost
Sure, but why store "empty" at all, in that case?
2015-12-09 34333, 2015
LordSputnik
Leftmost: well, we have to have the field, unless we have a editor_bio table
2015-12-09 34348, 2015
LordSputnik
(it's currently at editor.bio)
2015-12-09 34341, 2015
Leftmost
I'm just very confused as to why we'd want to store '' instead of NULL, rather than the other way around.
2015-12-09 34358, 2015
LordSputnik
Leftmost: because NULL is meaningless here :P
2015-12-09 34340, 2015
Leftmost
I'd argue that '' is meaningless here. :-P
2015-12-09 34305, 2015
LordSputnik
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
2015-12-09 34359, 2015
darwin
LordSputnik: I don't know the answer in postgres, in mysql it barely matters.
2015-12-09 34349, 2015
Leftmost
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.
2015-12-09 34359, 2015
Leftmost
If that sounds wrong to you, go ahead and go NOT NULL.
2015-12-09 34324, 2015
darwin
in my world, things which always should be set are NOT NULL
2015-12-09 34343, 2015
darwin
things which may not always be set may be NULLable, especially if NULL has a different meaning from "0" or "empty string"
2015-12-09 34357, 2015
darwin
but NULL complicates queries and does not generally save space on disk...
2015-12-09 34333, 2015
Leftmost
Yeah, I tend to see NOT NULL as indicating things should always be set.
2015-12-09 34344, 2015
chirlu`
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.
