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
2014-08-22 23427, 2014
voiceinsideyou joined the channel
2014-08-22 23413, 2014
Mineo
luks: but it's not urgent to get that pull request accepted at the moment :)
2014-08-22 23446, 2014
luks
Mineo: I was just curious :)
2014-08-22 23429, 2014
luks
you also use the trigger-based queue? or are updates based on something else?
2014-08-22 23404, 2014
ianmcorvidae
yeah, it's triggers and pg_amqp into rabbitmq
2014-08-22 23418, 2014
ianmcorvidae
(to answer a question directed at someone else. but anyway, heh)
2014-08-22 23432, 2014
navap
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?
2014-08-22 23418, 2014
navap
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
2014-08-22 23421, 2014
ianmcorvidae
manually passing it through would probably be the way, I didn't think about that
2014-08-22 23453, 2014
ianmcorvidae
I'm not sure why you'd be getting unblessed reference errors, unless you're doing $c->stash->foo rather than $c->stash->{foo}
2014-08-22 23406, 2014
ianmcorvidae
(i.e. the stash being unblessed, rather than $c being unblessed)
2014-08-22 23434, 2014
ianmcorvidae
but anyway $self->c largely only works for Data:: and such
2014-08-22 23413, 2014
navap
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
2014-08-22 23410, 2014
ianmcorvidae
I guess something's wrong about how it's getting passed then
2014-08-22 23425, 2014
ianmcorvidae
is this on rika (i.e. where I could look) or elsewhere?
2014-08-22 23429, 2014
navap
Oh and the $entity = $c->stash->{entity} results in Can't call method "stash" on unblessed reference
2014-08-22 23434, 2014
navap
It's local
2014-08-22 23428, 2014
ianmcorvidae
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);
2014-08-22 23406, 2014
ianmcorvidae
I'd guess it'll be some other argument and they're either in the wrong order or not enough are provided
2014-08-22 23437, 2014
navap
warn Dumper($c) results in
2014-08-22 23439, 2014
navap
$VAR1 = [
2014-08-22 23441, 2014
navap
'artist'
2014-08-22 23443, 2014
navap
];
2014-08-22 23450, 2014
ianmcorvidae
right, so it's the list-of-entities argument
2014-08-22 23409, 2014
ianmcorvidae
when calling this method it should be something like $self->the_method($c, ['artist']) presumably
2014-08-22 23434, 2014
ianmcorvidae
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
2014-08-22 23406, 2014
ianmcorvidae
you need $self->load_relationships
2014-08-22 23431, 2014
ianmcorvidae
if you're calling it as load_relationships(x, y) then x ends up as $self and y ends up as $c
2014-08-22 23406, 2014
navap
Ohh
2014-08-22 23414, 2014
navap
That $self stuff always confused me
2014-08-22 23415, 2014
ianmcorvidae
and presumably you don't need @objs since you don't use it (since you're loading on $entity, not anything in that)
2014-08-22 23427, 2014
navap
Yeah
2014-08-22 23407, 2014
ianmcorvidae
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, ...
2014-08-22 23429, 2014
ianmcorvidae
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"
2014-08-22 23442, 2014
ianmcorvidae
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"
2014-08-22 23446, 2014
ianmcorvidae
)
2014-08-22 23454, 2014
voiceinsideyou joined the channel
2014-08-22 23433, 2014
luks
ianmcorvidae: is the solr code somewhere on gh/bb?
2014-08-22 23453, 2014
ianmcorvidae
Mineo's stuff, you mean? it's a bunch of different repos but they're all on github
reosarevok: Add info about creating a DB to the docs
2014-08-22 23447, 2014
gabriel_ joined the channel
2014-08-22 23423, 2014
night199uk joined the channel
2014-08-22 23408, 2014
ruaok joined the channel
2014-08-22 23435, 2014
chirlu`
Moin ruaok! We assigned you some work. ;-)
2014-08-22 23449, 2014
ruaok
oy.
2014-08-22 23451, 2014
ruaok
moin!
2014-08-22 23425, 2014
Mineo
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)
2014-08-22 23406, 2014
ianmcorvidae
hm
2014-08-22 23426, 2014
ianmcorvidae
I'd noticed that yours used name/mbid rather than the ones the current one dit
2014-08-22 23429, 2014
ianmcorvidae
maybe that's only for works?
2014-08-22 23440, 2014
ianmcorvidae
no, seems to be the same
2014-08-22 23454, 2014
Mineo
oh, hm, then I screwed that up :(
2014-08-22 23430, 2014
Mineo
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)
2014-08-22 23449, 2014
ianmcorvidae
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
2014-08-22 23407, 2014
ianmcorvidae
yeah, I think we'd need to try it out
2014-08-22 23428, 2014
ianmcorvidae
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
2014-08-22 23408, 2014
ianmcorvidae
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?"
2014-08-22 23438, 2014
ianmcorvidae
so even if the weights are weird it might be fine
2014-08-22 23423, 2014
ianmcorvidae
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
2014-08-22 23427, 2014
Mineo
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 :)
2014-08-22 23433, 2014
ianmcorvidae
yeah
2014-08-22 23447, 2014
ianmcorvidae
do you have thoughts on how to deal with the field name changes that'd entail?
2014-08-22 23459, 2014
ianmcorvidae
(changes from current search server, not from what you've thus far done, I mean)
2014-08-22 23437, 2014
ruaok nods at chirlu`
2014-08-22 23453, 2014
ianmcorvidae
(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!)
2014-08-22 23432, 2014
ianmcorvidae
(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)
2014-08-22 23400, 2014
Mineo
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
2014-08-22 23417, 2014
ianmcorvidae
right
2014-08-22 23452, 2014
gabriel_ joined the channel
2014-08-22 23452, 2014
ianmcorvidae
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
2014-08-22 23410, 2014
Mineo
oh
2014-08-22 23416, 2014
ianmcorvidae
we could just stick it in both places, of course, but
2014-08-22 23414, 2014
ianmcorvidae
wouldn't put it past solr to have some sort of fancy query rewriter functionality built in though :)
which copies from 'name' to 'names', not 'work' to 'names'
2014-08-22 23448, 2014
ianmcorvidae
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
2014-08-22 23457, 2014
ianmcorvidae
(or whatever)
2014-08-22 23401, 2014
Mineo
now I wonder why I didn't do that for the other schemas
2014-08-22 23403, 2014
Mineo
yeah
2014-08-22 23454, 2014
ianmcorvidae
all of them seem to have mbid rather than arid, reid, rid, etc. too
2014-08-22 23422, 2014
Mineo
heh, I definitely need to look at that again
2014-08-22 23408, 2014
LordSputnik joined the channel
2014-08-22 23455, 2014
chirlu` joined the channel
2014-08-22 23410, 2014
itshim joined the channel
2014-08-22 23458, 2014
LordSputnik has left the channel
2014-08-22 23442, 2014
chirlu`
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.)
2014-08-22 23413, 2014
ianmcorvidae
er
2014-08-22 23420, 2014
ianmcorvidae
you mean you want it true except when $x is undefined?
2014-08-22 23408, 2014
ianmcorvidae
and I'm pretty sure the usual way is to directly compare against undefined and invert if necessary, but not sure
I see that MB.utility.validDate uses its own helper function “empty”, defined as “return value === null || value === undefined || value === "";”.
2014-08-22 23420, 2014
chirlu`
Maybe I’ll copy that.
2014-08-22 23425, 2014
ianmcorvidae
yeah, that may be the way to do it
2014-08-22 23408, 2014
ianmcorvidae
since JS separates null and undefined I'm not quite sure what you'd call it anyway, but
2014-08-22 23411, 2014
bitmap
(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
