#metabrainz

iliekcomputers: doesn't seem to work with the request context. nor gives it errors.

pristine_: yeah, we had to turn off the feature for what Mr_Monkey is working on.

ruaok: oh. I can try to fix it.

pristine_: I think it's not a problem anymore

Mr_Monkey: Okay :)

But thanks :)

maybe passing the sio object works?

ruaok: yep, trying that.

Mr_Monkey: You're welcome :)

can't seem to receive a message on the client...

nope no luck.

not sure if i'm doing something wrong.

let me push what I have so far.

do you need `with self.app.test_request_context('/'):` when you have a socketio object?

try without.

ooh

it is sending it _somewhere_

[listenbrainz-server] mayhem opened pull request #498: Make the spotify recorder a bit quieter (master...stfu-spotify-reader) https://git.io/fhVEA

i'm not sure if i'm handling it correctly.

handling it correctly on client or server?

the js client.

it used to work, but it might have changed now that we send them differently?

this is another handler i added for "message" events

so it kinda worked.

did you get anything in the client as a response to sending that message?

with the latest code? no.

i used to get stuff when I initially opened the PR.

only with the new socket connection?

[listenbrainz-server] mayhem closed pull request #498: Make the spotify recorder a bit quieter (master...stfu-spotify-reader) https://git.io/fhVEA

zbuttram is the best username of the week!

dat branch name ;)

this fixed it lol

and now it works as expected, to the right endpoint and all?

yes.

🖐️

this is a workaround, yes?

yes.

put something on the calendar to check next month if we can get rid of it.

but for now, let's finish this thing.

push changes to your branch?

will open a ticket.

then I'll merge into web-sockets

on your PR you have `need to look into serialization / deserialization need.`

not sure what that means. can I help resolve it?

so the data from rmq is a list of listens

with no guarantee of which user the listen belongs to

so we have to do a json.loads, get user, then json.dumps each listen again...

sure we dont need to reserialize it just to read the user name, no?

the bigquery queue for unique listens sends all unique listens in batches.

but passing both versions looks dumb in the code.

oh.

I had assumed that we'd be listening to that queue, not pre-influx one.

but we need think about latency here. we want low latency...

how do we handle duplicates if we listen to the pre-influx queue.

i'd suggest just moving forward with the data for now, get some songs playing and then look into fixing this too?

I dont think we should be listening to the pre-influx queue.

we aren't.

yeah, agreed.

ok.

another thing to manage is sessions.

at some point zas will get angry with us for the resources that LB is using.

then we can work on it.

ha! :D

what kind of sessions?

nice

like if I open of my own user pages, it adds them both to the room

*if I open two of my own user pages

lets get this merged and deployed on beta.

then we can see if this is a problem or not.

ok.

https://github.com/metabrainz/listenbrainz-serv... do you want to change anything here?

all good. should I merge?

yeah, sure.

(int web-sockets)

Mr_Monkey are you working on issue 313 .?

if not shall I take this issue .?

kartikpandey2: If you're comfortable with SQL, you can have a look at BB-320 which is the subtask that needs doing.

BB-320: Drop editors' date of birth from database https://tickets.metabrainz.org/browse/BB-320

ok, merged, iliekcomputers

You'll have to have a good look at how things are done in the sql folder in the repo

Mr_Monkey: Will you review my PRs today?

Mr_Monkey: Ok, I would love to take a shot, If I will not able to understand sql code I will reassign to you.

kartikpandey2: If you're not familiar with SQL? I'd rather you have a go at another ticket. It's quite critical.

akhilesh: Probably not today, I'm getting to the end of the day. But for sure tomorrow. Thanks for your patience

I know basic sql but I have not worked on sql.

btw why we choose sql, I believe nosql database would be more suitable for our need

ruaok: do you wanna deploy this ?

Because we like real databases :D

reosarevok: :D

reosarevok: we should use excel! :D

Mr_Monkey: I'm happy to drop stuff for you, if needed

I'm off to prepare for zas' arrival in bcn.

(I'm not sure I have access though)

as we can easily scale using nosql database like mongodb

If you can, please do.

kartikpandey2: we've had a great experience with postgres

Still, is it ready without Mr_Monkey 's stuff?

and moving would be a non-trivial amount of work.

Mr_Monkey: No worry, Review when you have time. Thanks :)

reosarevok: would you be willing to review kartikpandey2's work on that ticket?

ruaok: it would just log new listens to the console, so not sure if worth it.

probably not worth it yet, tbh.

IMO not very much

I'll do some prep for deploying.

Sorry for the delays :)

no worries at all.

Mr_Monkey: if all that needs doing is dropping a psql column, it doesn't need much review - ALTER TABLE user DROP COLUMN dob; or whatever

iliekcomputers: Ok, but I still think if our database gets big we will have problems to maintain that

kartikpandey2: we have TBs of data in postgres rn :)

iliekcomputers: Oh, great I use to think sql database can't handle large data.

but now It feels i was wrong lol xD

kartikpandey2: postgres is pretty cool! :)

ok ;)

`Sorry for the delays :)` beggars shall not be choosers.

Lolol

iliekcomputers: I told Mr_Monkey that when BB gets close to moving to hetzer, that you and I would retaliate his good deeds and work out how to host BB on docker/hetzner.

Yes, for sure.

I figure between you and I and what is already in place we can knock it out quick...

for some value of "quick".

ruaok: ping, around?