#musicbrainz-devel

it also opens up chances for things to get out of sync, where when it's all in the DB that's harder

(not that doing anything only through our WS is probably ideal in general given how it seems to frustrate everyone of us :p)

reosarevok: scripts, direct SQL

anything that isn't MBS itself but needs more access than the WS provides, basically

ianmcorvidae: I can see that there are other reasons, just wondering why we'd use them I guess :)

er. s/reasons/methods/

ianmcorvidae: but it should be safe if all interactions go through models, right?

well, we run direct SQL scripts against the DB twice a year :)

Gentlecat: yes, it's fine as long as you never want to use SQL directly or use any language but python

a great example is in tags, actually, where since our deletion process didn't work properly (by timing out before it completed), we ended up having to delete some tags manually

but stuff is (IIRC) *still* out of date with that because we haven't gone through to figure out exacly how to update it all

where if it had been done by the DB itself then the initial thing would have done it for us :P

yes

well, recalculating ratings shouldn't be that hard

anyway, as I said from the start: the triggers are the best/most ideal way, but are harder to wrap your head around and possibly harder to use with systems that don't like giving you access to advanced features, like sqlalchemy

so if it's not really feasible to do it with triggers, doing it in code is fine

stuff like sqlalchemy is nice, but the inherent goal of making a library that abstracts multiple sql engines is that it limits what you can do via the library :/

but you can add manually-written sql to the DDL statements to add triggers, etc...

I had to bang my head against it for I think 4-5 hours one night to finally find the documentation on how to do partial unique indexes

made me very annoyed :P

okay, I'll try to find more info and see how to do it

remember you'll also need functions, which aren't even tied to specific tables, so I don't really know where sqlalchemy would put them

there's one thing though

let's say we create a dump without private data (votes) and then import it

wouldn't postgres recalculate all the ratings and set them to 0 anyway?

only when the triggers would be called, which in a proper setup wouldn't happen then

hmm, for speed reasons, you don't normally want triggers enabled when importing a dump

you'd want to create triggers after importing the data (for performance, if nothing else)

ah, interesting

and since the triggers would then only be called on insert/update/delete on vote, there's not really a case where it'd come up

unless you're trying to use an imported server as a second master, which probably would end up resetting some things, but that's not really the intent

right, because I'm not even going to touch it during import

(could be changed by making the triggers just increment/decrement the appropriate things instead of fully recalculating, but that's also more dangerous/more likely to break)

so that shouldn't be a problem then

(e.g. pg_dump has the ability to disable triggers for you when doing the restore of data-only dump)

is recalculation usually done for all rows?

generally the trigger would only call the recalculating function for rows that do (or might) need updating

kepstin: I don't think we are going to use pg_dump for this, right?

who knows; it's an option.

I didn't really look at that yet

the alternative would be writing software to serialize data to a custom format, and then an importer for that format.

ianmcorvidae: so if new vote is created, it updates everything? or that depends on how I set up the function?

Gentlecat: you'd probably set it up so that if a new vote is created, it updates the review overall vote total by checking all the votes on the review

on insert, update, or delete of rows of the vote table, the trigger looks at the 'revision' column (both new and old values, if applicable) and calls the function to update those specific rows

kepstin-laptop: it's not at the review level

oh?

right, then I'm confused :)

it's per revision

revisions aren't really exposed publicly, but they do exist

kepstin-laptop: CB-68

anyway, the point is an MBS-compatible format, which is semi-custom

hmm, so that would mean writing custom serialization then :/

it's tab-separated, you pass the right arguments to psql it produces that

or not even that

MBS just does 'COPY $table TO stdout' and pipes it into a file :P

(and the importer code is just COPY FROM stdin)

ah, so you just have to generate a query that picks the correct stuff by licence, and let postgres to the work? :)

yeah

probably most easily just by creating a temporary table

(which is what we do for the editor table in MBS, since that needs sanitation)

gah. a tangled nest of DR tickets for CB. :(

Gentlecat: CB-65 what is the benefit of doing this?

no rush, I'm probably not going to fix these in the next couple of days anyway

well, I kinda want to get them decided. since I'm out for the rest of the week

65 is to show more interesting info about release group

it'd be a way to show more specifics about it, yeah -- barcodes, release countries, more than a single release date, alternate cover art, special editions, etc.

yeah, more info is always nice in general

if organized properly

without deeper features like letting reviewers mark which specific edition they have, I'm not sure I'd want to specifically have a section for "Here's the releases of this release group" or such

this page? https://critiquebrainz.org/release-group/163339...

but including things pulled from specific releases and (possibly/probably) grouping them in terms of which release that information came from, sure

ruaok: yep

catalog numbers and labels would be another thing to pull from releases

not sure I feel that we need to make CB match MB in every respect. the whole idea is to be easier on the eyes and not have so much data.

hm, something is wrong with spotify thingy

Gentlecat: seeing some js/css load errors from cloudfront, presumably that's the issue

probably transient

Gentlecat: why is CB-62 needed?

I would rather NOT do that.

gravatars

gravatars, yep

there's a field for email on CB anyway, and if you want your gravatar to appear you have to enter your email

got it.

I'd want it to be optional, anyway

right

something like "click here to copy your musicbrainz email to critiquebrainz"

or just a flag before login

or maybe during signup, "use my email address from musicbrainz" checkbox

I think it's not very intuitive that this happens at login, and I don't think we want to limit people to only being able to do it at signup

what is the discussion part relating to CB-57?

yeah, maybe doing that in profile editor is a better idea

hmm. there is no automatic syncing, right? so it's just a one-time copy?

kepstin-laptop: yeah, so presumably whenever you choose to poke the button (unless it's done automatically at login every time, of course)

ruaok: I'm not sure if we want to do this

I believe usernames are unique on mb

yes, they are.

they are, but not across deletion

specifically, if I go delete my account right now, I could then go create another one with the same name (since deletion results in a name change)

re unique display names, the video game solution is to identify everyone by (username,id-number) :/

but it's not a PK, we have uuid for users on cb

on gw2, I'm kepstin.6891 but it shows up as just 'kepstin' in most places unless there's a chance it'll conflict.

for the email thing, one way to do it would be a preference that says "use my MusicBrainz email", which turns on a flag that asks for that scope at login, and which also updates it immediately on submission of the preference form

which would then let it get updated any time you log in

(without needing to explicitly have users understand that that process is associated with login)

during the initial account creation process?

and if you uncheck that later in prefs, it disables the automatic email update and makes the email field manually editable?

oh, you mean flag in profile settings

kepstin-laptop: yeah, exactly

and yes, that

you'd probably want it to be something you can set at account creation as well, but it'd ultimately just be a preference

basically just a checkbox for "don't make me worry about setting my email, just manage it for me via MB"

so is it, or do we want it to be, possible to use critiquebrainz without a musicbrainz account?

that's currently out of the picture

it was before I came :)

the original plan included twitter login, but it's also a lot of complication

there was twitter auth also

forcing musicbrainz accounts only is mostly intended for letting us worry more about actual features :P

makes sense.

and coming back to username question... https://github.com/metabrainz/critiquebrainz/bl...

this method usually gets username from mb during account creation

but I had problems there during BBC dump importing, hence the CB-57

one question to answer is: is this a problem outside of importing?

I guess I can just make it better if we want to leave usernames not unique

outside of importing, no

for things like that the real solution would be to have a more general system for linking users to identities from elsewhere (wherever that may be)

vs. now where we basically just tie the user to MB

given that the BBC stuff is already imported it might not matter at any point in the near term, anyway, if this is a problem that only applies to importing

unless there's some shortly-incoming review dumps coming our way that I don't know about, of course, but :P

it will probably be easier to tweak functionality for each dump import

or write some kind of converter into our format

let's leave it as it is right now. I'll try to improve User model

should this discussion be noted on the ticket?

should I link it and close the ticket?

plz

done

bitmap: where is the latest version of your Batch-add "performance of" relationships script now that userscripts is down ?