ruaok: can you ping me when you're around? Got a few questions about LB tests
ruaok
Moin. Still Out running some errands... Will ping in an hour or so.
alastairp
OK, I'm in no rush. see you later
yvanzo
reosarevok: thanks, I fixed it.
Nyanko-sensei has quit
Nyanko-sensei joined the channel
ruaok
hour? whatever. what'cha got, alastairp ?
alastairp
ruaok: you added your tests to integration tests. Is that because this was the only place that had the timescale db set up?
because based on what I understand from these tests, your stuff would fit better in the unit tests (it's just putting in/reading from the db)
it seems like the integration tests are for testing pipelines - stuff goes in, gets queued, gets picked up, etc)
it makes sense to me that we create TS tables in the unit tests, and add these playlist tests to the unit tests section
ruaok
hmmm.
I went looking or the API tests and couldn't find them, then remembered that they are in the integration tests, then added the tests there.
that is to say, I hadn't really considered the question. now that you mentioned it, not sure why that is.
I can try to move them to unit tests and see if anything asplodes.
alastairp
there is a tomato/potato question about what the boundary is between unit/int tests
my thought was that the integration tests only existed because we had data flowing through a pipeline of multiple services
*my understanding
ruaok
I'm actually with you -- given that we *can* put them in unit tests, why not?
alastairp
cool
I don't mind doing that - because I'm right at the point where I need TS in the unit tests for DB tests
ruaok
cool, perfect. thanks.
alastairp
so I'll add TS to the test setup, and move yours (after taking a look to see if it fits in with other tests)
ruaok
I'll try and focus on finishing that troi branch I promised to have done more than a week ago.
great
any chance you can look at the mega branch mbid-mapping soon?
alastairp
you said cool, perfect, and thanks. so now I need to come up with another one word reply indicating agreement that doesn't make it seem like i'm just copying you
I have the tab open, and it's on today's list
ruaok
brilliant!
;-0
alastairp
OK, interesting. there are a small handful of view tests in the unit tests, but you're right that all API tests are in integrations.
definitely something to double-check with iliekcomputers if we can grab his time for 5 minutes
abhinavohri joined the channel
abhinavohri
@alastairp I have some doubts related to my two PRs.
v6lur joined the channel
CatQuest
so, how long since I asked to change my email adress on the wiki should I except to get that confirmation email?
BestSteve has quit
BestSteve joined the channel
expect*
sumedh has quit
sumedh joined the channel
bitmap has quit
zas
a forum user cannot log in after he changed his email address on MB, known issue?
bitmap joined the channel
reosarevok
Freso: ^ ?
(not known to me)
zas
He gets "There is a problem with your account. Please contact the site's administrator" error even from a fresh browser window (new browser, no cookies)
reosarevok
This is in discourse, not MB proper, right?
zas
yes
I'll enable SSO verbose logging and see what's going on
reosarevok
Maybe the stuff that should propagate updates to discourse broke or something. I'm not sure how that is set up though
ruaok: I want to run some more database/testing stuff past you
ruaok
k
alastairp
timescale tests currently drop db/createdb after each test. unit tests don't drop the db, they just remove all of the tables
ruaok
I've slowly been working to make TS tests more robust.
namely, so that sequential tests can be run on the same DB, so that we can setup the DB once for any given test run.
alastairp
docker postgres has this functionality to create a db and a user at startup time. I'm wondering if this would be a nice thing to do. In my view it's the correct way to do it
ruaok
e.g random user names for each run.
alastairp
ah, cool. I think that ties in with the direction that I want to go too, then
ruaok
yeah, I think we're on the same path.
alastairp
because there are a _lot_ of moving parts here - lots of different test superclasses that do slightly different things
ruaok
effectively I want the tests to be ... not idempotent, but.. isolated
?
alastairp
yeah, I see what you mean
another way I've seen these kind of tests work, at the beginning of each test a transaction is started, and then it's rolled back at the end. This is a lot faster than tearing down database tables after each test
but that's for another day, I think
ruaok
that would work too...
alastairp
oh, I guess I understand the reasoning for not creating db on container startup for LB - it's because we have both LB and MsB stuff in the same database cluster
now I remember
so now the question is do we keep things consistent between TS and regular PG cluster, or do we do setup differently in each?
ugh, I'm opening a can of worms here, but for LB dev, there's really no reason to not just use the TS cluster for all 3 databases, right??!
ruaok
make TS better. I don't see the importance of consistency here. just document that they do things differently.
TS can be used for all.
part of the current state of things is because we haven't drank the kool aid on TS yet.
alastairp
I'll open a ticket for that
ruaok
but I'm ok with it now. its been solid and I've been enjoying having it.
shivam-kapila
Are you talking about migrating postgres stuff to TS in lb
alastairp
shivam-kapila: just using the same server process for all databases
shivam-kapila
Okay okay
alastairp
because timescale _is_ postgres, just with an extension
so it seems a waste to start 2 postgres servers. Let's just start one, and use it for all 3 of our databases (listens, user data, messybrainz)
