not friendly for human searchers, but fuck humans.
2021-08-10 22220, 2021
alastairp
two things that come to mind which I'd try next:
2021-08-10 22231, 2021
alastairp
maybe something with query time boosts - to say that some things are more important than others
2021-08-10 22220, 2021
alastairp
and just throwing out an idea - did you try making recording names multi valued? it's possible that there are some solr functions that can tell you how many values in a field matched your search query, you could use that + a boost
2021-08-10 22248, 2021
ruaok
I haven't done either of those -- just starting to tune them.
2021-08-10 22213, 2021
ruaok
let me check out multi-valued fields, that sounds much more useful than just boosts
2021-08-10 22210, 2021
alastairp
in fact, all of your fields appear to be multi-valued already - given the [] surrounding them :)
2021-08-10 22256, 2021
ruaok
yes, indeed.
2021-08-10 22203, 2021
ruaok
but I am not certain this is going to help.
2021-08-10 22202, 2021
ruaok
I think I need to build some serious test cases and expected results before I can work towards a solution.
2021-08-10 22203, 2021
alastairp
yeah, I was just hypothesising that there was a percentage_fields_match(recording_names, 75) function that you could call to boost certain results
2021-08-10 22210, 2021
ruaok
but I get the feeling that solr alone won't cut it.
2021-08-10 22221, 2021
alastairp
agreed, I'm throwing out ideas without really knowing your requirements and test cases
2021-08-10 22206, 2021
ruaok
let me whip up some test cases to shore up the ideas.
Actually recordings are the same already, but because the "Recording artist" was specified, I thought it was a specific relationship, so different recordings.
2021-08-10 22248, 2021
ruaok
the taste of honey works as a good test case. my results already are:
Could you be more specifc about "restricting options up to two possible relationship types is not the same as auto-selecting two relationship types"?
2021-08-10 22244, 2021
yyoung
Now I'm thinking if it's better to split the logic
2021-08-10 22208, 2021
yvanzo
yyoung: a <select> element with two options vs two <select> elements with freezed options
2021-08-10 22241, 2021
yvanzo
"frozen"
2021-08-10 22249, 2021
yyoung
Are we auto-selecting those 2 types all the time?
2021-08-10 22216, 2021
yyoung
It did show 2 options in the select
2021-08-10 22230, 2021
Etua joined the channel
2021-08-10 22247, 2021
yyoung
But that's why I'm thinking about splitting :)
2021-08-10 22250, 2021
yvanzo
Not all the time: Mainly Norfolk & Jamendo have auto-select, Internet Archive don’t.
2021-08-10 22251, 2021
Etua has quit
2021-08-10 22207, 2021
yyoung
Let's focus on jamendo here
2021-08-10 22226, 2021
yvanzo
Yes, Jamendo always provides both download and streaming options.
2021-08-10 22245, 2021
yvanzo
So both relationship types should be auto-selected.
2021-08-10 22217, 2021
yyoung
How is this issue represented in the UI?
2021-08-10 22237, 2021
yvanzo
It would be better represented using the other PR.
2021-08-10 22240, 2021
yvanzo
Since relationships are grouped by URL, auto-selected relationship types (download and streaming) cannot be removed separately, but the URL can.
2021-08-10 22207, 2021
yyoung
Hmmm...
2021-08-10 22220, 2021
yyoung
Actually I was thinking using 'types' to validate rel types combination
2021-08-10 22221, 2021
yvanzo
It’s the same for only 1 auto-selected relationship type.
2021-08-10 22249, 2021
yyoung
I haven't thought about how to lock the 2 rels together in the UI
2021-08-10 22230, 2021
yvanzo
You probably need a flag 'autoSelected' for each relationship.
2021-08-10 22253, 2021
yyoung
So you're suggesting changing to '[LINK_TYPES.downloadfree, LINK_TYPES.streamingfree]' ?
2021-08-10 22201, 2021
yyoung
My initial thought was to use 'types' to limit possible type and type combinations, if there's only a single type when validating and it's not in the array, then we could show the error
2021-08-10 22246, 2021
yyoung
So here it implies that Jamendo links can only have 2 type together, not any single type
2021-08-10 22204, 2021
yvanzo
Yes
2021-08-10 22254, 2021
yyoung
Therefore after splitting this mechanism no longer works.
2021-08-10 22240, 2021
yvanzo
No, you have to check relationship types from the UI against auto-selected relationship types.
2021-08-10 22259, 2021
yvanzo
... at first (then against 'types' if no rel type has been auto-selected).
2021-08-10 22229, 2021
reosarevok
bitmap: for when you're around, I'm looking into MBS-11862
What places do you think we should still show the deprecated types?
2021-08-10 22205, 2021
reosarevok
Obviously they need to be shown in the /relationships page to be able to edit them at all
2021-08-10 22224, 2021
yyoung
reosarevok: FYI, my PR also affects deprecated types
2021-08-10 22229, 2021
reosarevok
And we don't want them in the release editor, relationship editors
2021-08-10 22255, 2021
reosarevok
yyoung: deprecated types will still be available to you in the URL editor, unless they have 0 uses as well :)
2021-08-10 22215, 2021
reosarevok
bitmap: what about statistics? thinking not? edit search - thinking yes?
2021-08-10 22251, 2021
bitmap
reosarevok: if they still have uses I'd probably keep them in stats and docs, otherwise I'd hide them everywhere?
2021-08-10 22256, 2021
yyoung
reosarevok: It seems one of the features has already eliminated some of them :)
2021-08-10 22205, 2021
reosarevok
bitmap: Without uses, I mean :)
2021-08-10 22230, 2021
reosarevok
Having them in the edit search lets us search for edits that used them, which might be useful? Dunno
2021-08-10 22232, 2021
yyoung
yvanzo: So how is this different from directly checking against 'types'
2021-08-10 22252, 2021
bitmap
reosarevok: edit search is the only place I could see them being useful
2021-08-10 22206, 2021
reosarevok
In any case, we can't stop showing them under /relationships or we will be unable to make any change if we ever need to :)
2021-08-10 22210, 2021
reosarevok
So I would still show them there
2021-08-10 22230, 2021
yyoung
Currently I haven't hide the type selectors when auto-selecting type combination
2021-08-10 22249, 2021
bitmap
you could hide them from non rel editors if it matters
2021-08-10 22232, 2021
reosarevok
I thought about that
2021-08-10 22242, 2021
yvanzo
yyoung: 'types' allows to select any number of relationship types in a set, it doesn’t make mandatory to select them all.
2021-08-10 22256, 2021
reosarevok
But it seems... harder :) (in that I'd need to pass a specific extra value to see if they have 0 uses)
2021-08-10 22213, 2021
reosarevok
And I think it might be of some use to have them there, at least so that if someone sees them in the edit search, they can figure them out
2021-08-10 22228, 2021
yvanzo
yyoung: It would probably make more sense if based on the other PR.
2021-08-10 22238, 2021
yyoung
Yes I think so
2021-08-10 22246, 2021
reosarevok
We *probably* should have something there like "This type has been removed and is only kept for historical data" or something?
2021-08-10 22257, 2021
reosarevok
If seeing the specific page of the type
2021-08-10 22204, 2021
yyoung
Will we allow users to select more types if it's already auto-selected?
2021-08-10 22237, 2021
yyoung
IIUC the current code would force users to select both 2 types
2021-08-10 22239, 2021
yvanzo
yyoung: No, just the same as it is currenly with 1 auto-selected type.
2021-08-10 22232, 2021
yvanzo
It's auto-selected, they don’t have to select them.
2021-08-10 22240, 2021
yyoung
Let me explain my ideas: Based on the other PR the links are already grouped, then I'll take all relationships under a URL to check it against 'types', whether it's a single type or multiple types
2021-08-10 22224, 2021
yyoung
By 'multiple(rel1, rel2)' it enforces to select both of them at the same time
2021-08-10 22258, 2021
yyoung
While 'rel1, rel2' allows only one of them, excluding the combination
2021-08-10 22227, 2021
bitmap
reosarevok: sounds okay to me. I'd probably display (deprecated) next to them in the edit search options too
