I think a commit may have gotten lost here. I recall importing the name of the index from the mbid_mapping module.
MajorLurker has quit
alastairp
_lucifer: after you make a commit for updating the image versions, can you make another one which reorders items in lemmy.sh to put all prod items first, and then a newline and then all beta items
_lucifer
yes, sure will do that
we should look into the automating image building sometime soon, it'll help ease out the release process
alastairp
ruaok: when you're done with this testing lmk, got a question to run past you about mb2wikidatabot
ruaok
go, I'm idle, waiting for tests.
alastairp
_lucifer: absolutely. please write a ticket that includes all of the "strange" things that you've learned about deploy
ruaok
but reosarevok is more of the maintainer of that now.
alastairp
ruaok: in other python apps, we now have this pattern of creating runit scripts, adding `down` to all of them, and then in rc.local looking at $CONTAINER_NAME and removing the down. However mb2wdbot is only ever one service
so I guess we probably shouldn't over-complicate this one, and just making the service start unconditionally is fine. what do you think?
normally if we have problems with the service, we take it down.
alastairp
I saw a great tweet a few weeks ago, it basically said "when you encounter a new project, make a wtf list. this contains all of the things that strike you as odd, it's likely that everyone on the project has become desensitised to all of them and think it as normal"
ruaok
I did that with funkwhale, but the maintainer is burnt out and didn't really give a flying fuck about this feedback, which was sad.
_lucifer
ruaok: can you once take a look at the other queries as well?
so we only have this small period of time before _lucifer gets desensitised to our deploy process. we need him to say "wtf, why do you have to do such a convoluted process to deploy"
ruaok: yeah, that sucks
ruaok
_lucifer: that's a backend data issue. please release for now, I'll see about building this index.
#2 stands out, but I feel that that is a bit non-standard.
#3 is my fave, I think.
shivam-kapila
Mine too
4th isnt much mobile friendly
Mr_Monkey
Yeah I had the same worry about #4. It wouldn't have that right-left effect on mobile, and coding that would be challenging
shivam-kapila
Mr_Monkey: can you move the date/time to RHS in 3rd
ruaok
#2 would be good for other types of data, but I think people have some ideas as to what a timeline should look like.
Mr_Monkey
shivam-kapila: you should have edit powers, try now
_lucifer
i like 3 as well. how about also grouping cards? like if a user shared multiple songs, it says anonymous shared multiple songs and then the cards in that category.
Mr_Monkey
I like that idea.
grouped by what time range, though?
_lucifer
yeah time range or if there is no other timeline activity between those two events
or a mix of both of those
If there is no other activity and the events take place within a given time range, then the similiar ones get grouped. (a group of likes, another of recommendations etc.)
reosarevok
Hmm. I like 2 because it doesn't say "I'm fucking Facebook"
But then, ruaok might be right "fucking Facebook" is what people expect from a timeline nowadays :D
Mr_Monkey
Thanks for your feedback !
reosarevok
Anyway, none of them are bad, so if you do any of them, I'd be happy enough :D
iliekcomputers: we should be careful about the index type on the enum field.
iliekcomputers
ruaok: i was gonna ask you to elaborate
ruaok
if we end up doing searches for events with a particular type and we have 5 types and 10M rows (lets say spread evenly), and then we wish to do a search we will end up having to scan 2M rows that have the same type.
this used to be a big problem for MB and the edit table. but a lot of time has passed since those days and I don't know if this is still a concern.
googling hasn't really revealed any clear suggestions.
iliekcomputers
will we be doing queries that have just an event_type ? I added an index on user_id, event_type as well for queries like user_id = X and event_type = 'recording_recommendation'
ruaok
I can't think of a use case right now, TBH. but given that I was burnt by this as a child, I try to prevent this from happening in the future. :)
iliekcomputers
mhmm, makes sense. I assume we might do queries in the future based on event_type and things in the metadata field, but then we can either extract those fields out of metadata and create indexes (or just create indexes on the json).
Etua joined the channel
Etua has quit
so about the timeline design, are we all ok to go with #3?
ruaok
fine by me.
iliekcomputers
cool, then i guess next steps would be for Mr_Monkey to use the current endpoint to build the frontend and then we can change the endpoint to send better data. right now it sends all listens, we can filter those, and eventually add track recommendations etc as well.
iconoclasthero joined the channel
Mr_Monkey: what do you think?
iconoclasthero has left the channel
shivam-kapila
Mr_Monkey: sorry I had to go to get my phone repaired
ruaok
iliekcomputers: I think that PR now looks good -- how about the spec for what to stuff into the metadata JSONB field?
iliekcomputers
i'll create a pydantic model in the next PR.
ruaok
ok.
iliekcomputers
with the API endpoint.
ruaok
iliekcomputers: may I take over the param/neighbours PR?
iliekcomputers
for sure.
Mr_Monkey
Yes I think I can start building the page with the existing endpoint
ruaok
I will make a new branch and cleanup first, then close that PR and replace it with another one later.
iliekcomputers
Mr_Monkey: awesome, thanks!
ruaok: sounds good.
atj
I like the vertical line style on #2
BrainzGit
[listenbrainz-server] mayhem closed pull request #967 (master…param/neighbours): [wip] Neighbours: User similarity based on Collaborative filtering on artist stats https://github.com/metabrainz/listenbrainz-serv...
atj
makes it more readable to me for some reason
Mr_Monkey
Good to know
atj
that's my unsolicited opinion :P
ruaok
we did solicit opinions. :P
BrainzGit
[listenbrainz-server] paramsingh merged pull request #1309 (master…param-user-recommendation-event-table): Add new table for user recommendation events https://github.com/metabrainz/listenbrainz-serv...
atj
they look great by the way, I look forward to seeing it live
do draft pull requests also send notification emails on every push?
ruaok
they do.
iliekcomputers
got it.
ruaok
I can close it again after I get basic things squared away if you prefer that.
iliekcomputers
nah, no worries. i just like to open pull requests and push to see build results generally after testing things I've touched, but it's not really necessary if it's sending an email on push to everyone :)
ruaok
yeah, same feelings here.
the PR page is just such a nice summary of the state of the branch.
atj
ruaok: has anyone floated the idea of a "buy this track on Bandcamp" type link on LB?
ruaok
not yet.
ruaok is stil a bit sad that the CEO of bandcamp continues to ignore my mails, even after numerous re-introductions.
atj
ah, that sucks
Bandcamp seem to be one of the "good guys" (although it's a low bar)
ruaok
bandcamp would be a great company to work with, but they would like nothing to do with us. or me.
reosarevok: iirc it had to do with the fact that linked_entities gets modified while it's being looped over. but there wasn't an easy fix outside of removing linked_entities