e.g. l_artist_work for an arranger relationship, the entity1 cardinality would be 0 and the entity0 cardinality would be 1
2017-10-31 30409, 2017
bitmap
because an artist may have arranged many works but a work would only have one or few arrangers
2017-10-31 30423, 2017
samj1912
So 1:M rels?
2017-10-31 30439, 2017
samj1912
Or somewhere close
2017-10-31 30452, 2017
bitmap
close enough
2017-10-31 30404, 2017
bitmap
both sides are unbounded but it's based on what we expect
2017-10-31 30421, 2017
samj1912
Cool
2017-10-31 30422, 2017
bitmap
we only use this for display
2017-10-31 30434, 2017
samj1912
But we index everything?
2017-10-31 30459, 2017
bitmap
in the current search server? I have no idea
2017-10-31 30415, 2017
bitmap
I'd expect not
2017-10-31 30418, 2017
samj1912
In our plan for solr
2017-10-31 30436, 2017
samj1912
In the current search server very few fields are indexed
2017-10-31 30442, 2017
samj1912
We should figure out a common field schema and representation for all rels
2017-10-31 30428, 2017
samj1912
So lets say artist rels are displayed in the same way for release and recordings (does that make sense?)
2017-10-31 30439, 2017
bitmap
to display them, don't they have to be in a document, i.e. indexed? I guess I don't understand why they'd be different
2017-10-31 30412, 2017
samj1912
We display them in a slightly different way
2017-10-31 30435, 2017
samj1912
We construct a _store variable that we store the xml to be displayed in
2017-10-31 30442, 2017
samj1912
And then we index the _store field (however it's not meant to be searched) we then convert the xml to a Java object and then marshall it back to xml or json appropriately
2017-10-31 30419, 2017
samj1912
So its not necessary to have all the displayed fields searchable (which is the reason we have extra_paths arg in the schema for sir entities)
2017-10-31 30452, 2017
agentsim_ has quit
2017-10-31 30420, 2017
bitmap
ok, I guess I was confused on the terminology (they are indexed but not searchable)
2017-10-31 30445, 2017
samj1912
Yeah sorry, I will fix that
2017-10-31 30406, 2017
bitmap
are the only relationship fields that are actually searchable currently on the url entity?
2017-10-31 30437, 2017
samj1912
No, there are others too
2017-10-31 30452, 2017
samj1912
They are listed in the schema file for sir i linked above
2017-10-31 30415, 2017
samj1912
Eg release types in recordings
2017-10-31 30429, 2017
samj1912
And mbids/names of related entities
2017-10-31 30420, 2017
bitmap
by relationship I specifically mean from the l_ tables
2017-10-31 30428, 2017
bitmap
I thought that's what we were talking about
2017-10-31 30405, 2017
samj1912
Oh, I meant general foreign key relationships
2017-10-31 30435, 2017
samj1912
I guess from L tables we have places and areas for events
2017-10-31 30453, 2017
bitmap
so rels == fks in this entire doc? that wasn't clear at all :)
2017-10-31 30410, 2017
samj1912
Yes :p
2017-10-31 30414, 2017
bitmap
sorry, 'relationship' has a very specific meaning in mb
2017-10-31 30455, 2017
samj1912
Uh yes let me fix that
2017-10-31 30421, 2017
samj1912
bitmap: is that better?
2017-10-31 30450, 2017
agentsim joined the channel
2017-10-31 30416, 2017
bitmap
we don't need to decide what is indexed, I thought? just what is displayed and what is searchable
2017-10-31 30418, 2017
samj1912
Fixed terminology
2017-10-31 30440, 2017
samj1912
Sorry if this was confusing 😅
2017-10-31 30459, 2017
bitmap
"Which fields of a foreign key constrained entity should we display" <- that's a bit confusing too, but I assume you are just talking about top-level entities, outside of relationships
2017-10-31 30451, 2017
bitmap
or do you mean thinks like the artist area
2017-10-31 30454, 2017
bitmap
things*
2017-10-31 30415, 2017
reosarevok
ruaok: "Re: Please verify your email address" is in German, in case you feel like German-ing
2017-10-31 30423, 2017
bitmap
i.e. entities linked directly to other entities outside of relationships
2017-10-31 30448, 2017
reosarevok
(otherwise I'll just answer in English)
2017-10-31 30436, 2017
bitmap
artist area, release label, track recordings, etc., as distinguished from the top-level entities for the requested resource?
this document might be better with specific examples: should we display field x inside element (path) y in request z, and should it be searchable?
2017-10-31 30429, 2017
samj1912
Yes
2017-10-31 30404, 2017
samj1912
I will fix it up tomorrow morning then
2017-10-31 30416, 2017
samj1912
It's late here, good night
2017-10-31 30458, 2017
bitmap
thanks, sleep well
2017-10-31 30430, 2017
jsturgis has quit
2017-10-31 30409, 2017
madmouser1 has quit
2017-10-31 30455, 2017
ruaok german-ings it
2017-10-31 30405, 2017
SothoTalker_
yes, germanize everyone \o/
2017-10-31 30400, 2017
gcilou
there's a kid dressed up as forest gump running around campus and everytime he passes my window, he has a larger group of people running after him
2017-10-31 30410, 2017
gcilou
Halloween is great
2017-10-31 30413, 2017
SothoTalker_
totally
2017-10-31 30459, 2017
SothoTalker_
but maybe he is just a thief and followed by an angry mob trying to get their goods back :D
2017-10-31 30441, 2017
MajorLurker joined the channel
2017-10-31 30428, 2017
jsturgis joined the channel
2017-10-31 30420, 2017
github joined the channel
2017-10-31 30420, 2017
github
[listenbrainz-server] paramsingh opened pull request #284: LB-206: Show playing_now submissions on user page (production...now-playing) https://git.io/vFYHc
