#musicbrainz-devel

luks: sorry, very late answer: yes, at the core there's a modified version of the path-based attribute-walking approach of the search code in mbdata

luks: but it's not urgent to get that pull request accepted at the moment :)

Mineo: I was just curious :)

you also use the trigger-based queue? or are updates based on something else?

yeah, it's triggers and pg_amqp into rabbitmq

(to answer a question directed at someone else. but anyway, heh)

ianmcorvidae: Just to be clear, the relationship wrapper controller role isn't using an `after` right? So then how do I pass through $c to get acces to the current stash?

I get unblessed reference errors when I try using $self->c or even if I manually pass $c through as an argument to the method in the role

manually passing it through would probably be the way, I didn't think about that

I'm not sure why you'd be getting unblessed reference errors, unless you're doing $c->stash->foo rather than $c->stash->{foo}

(i.e. the stash being unblessed, rather than $c being unblessed)

but anyway $self->c largely only works for Data:: and such

So I'm passing $c through manually now. I have a call using $c->model('Relationship')->load_subset() and I get Can't call method "model" on unblessed reference

I guess something's wrong about how it's getting passed then

is this on rika (i.e. where I could look) or elsewhere?

Oh and the $entity = $c->stash->{entity} results in Can't call method "stash" on unblessed reference

It's local

anyway, presumably the order of arguments is broken or it's being called somehow incorrectly; you might be able to figure out exactly what it's currently thinking is $c by use Data::Dumper; warn Dumper($c);

I'd guess it'll be some other argument and they're either in the wrong order or not enough are provided

warn Dumper($c) results in

$VAR1 = [

'artist'

];

right, so it's the list-of-entities argument

when calling this method it should be something like $self->the_method($c, ['artist']) presumably

if you have something in the method like my ($self, $c, $entities) = @_;

And then I have load_relationships($c, ['artist'], $artist) in the artist controller

you need $self->load_relationships

if you're calling it as load_relationships(x, y) then x ends up as $self and y ends up as $c

Ohh

That $self stuff always confused me

and presumably you don't need @objs since you don't use it (since you're loading on $entity, not anything in that)

Yeah

and yeah, $whatever->$meth($a, $b) means "look for $meth on $whatever and its superclasses, then call what you find first with $whatever as the first argument, then $a, $b, ...

and the 'blessed' stuff is basically what lets it know what classes/superclasses to consider, blessing just basically says "see this object? consider it a Foo::Bar::Baz"

and the documentation page for 'bless' uses very MB terminology :P http://perldoc.perl.org/functions/bless.html ("this function tells the thingy referenced by REF that it is now an object in the CLASSNAME package"

)

ianmcorvidae: is the solr code somewhere on gh/bb?

Mineo's stuff, you mean? it's a bunch of different repos but they're all on github

lemme collect linsk

links*

https://github.com/mineo/sir is the main orchestrator, https://github.com/mineo/mbsssss is solr config files, https://github.com/mineo/mb-solrquerywriter/ rewrites to mmd-schema/json

https://github.com/mineo/mb-rngpy/ is installed by requirements.txt by one of those (sir, I think)

yeah, by sir. as is mbdata, of course

thanks

presumably-obviously requires an MB database, solr, pg_amqp, and rabbitmq as well, of course :)

oh, and note that labels don't seem to work right now, I think since mbdata maybe hasn't been updated for removal of label sortnames

hm, separate core for each entity?

I'd actually asked Mineo roughly the same, I'm not sure why he did it that way

I always assumed it will be faster if you build just one index, because there is a large overlap

but I never tested that

presumably also makes a unified search (where it's sensible) easier

so I tend to agree with what you're saying, but maybe there's something I don't know, so hopefully Mineo will chime in at some point

reosarevok: fixing doc

haha

Forgot that also appeared here

haha

Ian McEwen: Fix up release event importing more generally.

Project geordi build #20: SUCCESS in 35 sec: http://ci.musicbrainz.org/job/geordi/20/

reosarevok: Add info about creating a DB to the docs

Moin ruaok! We assigned you some work. ;-)

oy.

moin!

ianmcorvidae, luks: there's separate code for each entity for reasons of compatibility with the current search server: while there's a large overlap in the data (name, aliases, ...), the field names tend to be different (the name of an entity is usually saved in a field with the name of its type, not in "name", for example)

hm

I'd noticed that yours used name/mbid rather than the ones the current one dit

maybe that's only for works?

no, seems to be the same

oh, hm, then I screwed that up :(

it's probably possible to just add everything into one index, but I'm not sure what the implications of that for search results would be - artists, for example, tend to have more aliases than works (if you ignore classical), so if you'd do a unified search on just names of things, artists might always get a better score than works (at least I think that's something that could happen)

but either way I guess it needs to be figured out, whether we change to the more reasonable names like name/mbid and a unified index (which I'd prefer, but it'd probably need some sort of query rewriter or something? unsure) or keep it split but then we need to figure out how to implement unified search

yeah, I think we'd need to try it out

that being said, if you're searching for a name, it's not that much more common that there's a duplicate between artist vs. recording (say) than two artists

ultimately search is more often a "hey, I have this string thing here that sort of describes what I care about, what do you know about things that might be it?"

so even if the weights are weird it might be fine

if you're searching for 'love' or something you're going to have to know whether you want a work or a recording no matter what, this just means you don't have to when you're searching for something more unique

in the end, merging all the xml schemas and changing the code to just write everything to one solr core shouldn't be hard to do :)

yeah

do you have thoughts on how to deal with the field name changes that'd entail?

(changes from current search server, not from what you've thus far done, I mean)

(bonus: having one 'mbid' field that's shared across entities means we have a dedicated non-hacky way to resolve what entity type any MBID is!)

(vs. the stuff we do for /ws/js/entity where it just tries artist, sees if it gets one, tries area, etc. until it finds one or runs out of entities XD)

I think some searches support the same fields under different names (both release/recording support searching for the number of tracks on the medium/release as a whole, but they're named differently), but I can't think of any conflicts right now

right

I guess I was meaning, how do we make it so someone searching for something like entitytype:artist artist:(Artist name) doesn't start suddenly getting no results since the field should be 'name' rather than 'artist' now

oh

we could just stick it in both places, of course, but

wouldn't put it past solr to have some sort of fancy query rewriter functionality built in though :)

ah, wait, I didn't screw that name thing up!

because solr allows you to provide automatic copies of field values under different field names, e.g. https://github.com/mineo/mbsssss/blob/master/la...

no, that's the only one that has it as 'label' rather than 'name'

see e.g. https://github.com/mineo/mbsssss/blob/master/wo...

ah

which copies from 'name' to 'names', not 'work' to 'names'

sadly we can't just use copyField on a unified index since searching for something like artist:foo means different things on an artist vs. a work search

(or whatever)

now I wonder why I didn't do that for the other schemas

yeah

all of them seem to have mbid rather than arid, reid, rid, etc. too

heh, I definitely need to look at that again

What’s the JS equivalent to “if (defined $x) { … }”? (Where $x may be undefined, null, or 0, and I don’t want the condition to be true for 0.)

er

you mean you want it true except when $x is undefined?

and I'm pretty sure the usual way is to directly compare against undefined and invert if necessary, but not sure

Oh, wrong.

null → false, undefined → false, 0 → true, 1 → true.

ah

I see that MB.utility.validDate uses its own helper function “empty”, defined as “return value === null || value === undefined || value === "";”.

Maybe I’ll copy that.

yeah, that may be the way to do it

since JS separates null and undefined I'm not quite sure what you'd call it anyway, but

(x || x === 0) is probably sufficient for what you want...I think the empty() function could use it, too, but I can't remember if it needed to handle NaN values or something