@ruaok hey, Apple has updated their license agreement. can you log into your Apple developer account and accept the new license agreement for MB? Picard notarization will not work otherwise :(
2020-04-07 09812, 2020
ruaok
on it.
2020-04-07 09826, 2020
outsidecontext
thanks
2020-04-07 09820, 2020
outsidecontext
ruaok: hope you are all well. how is the situation in Barcelona?
2020-04-07 09857, 2020
ruaok
improving. the city is quiet for the first time ever, from what I can tell.
2020-04-07 09828, 2020
ruaok
I'm doing well, you?
2020-04-07 09841, 2020
outsidecontext
yes, but that's currently a strange feeling with empty cities everywhere.
2020-04-07 09825, 2020
outsidecontext
all good here so far. people around really take this serious and act accordingly and keep distance.
2020-04-07 09838, 2020
ruaok
hmmm. two factor auth is not working. I think bitmap may need to do this step. bitmap ^^
2020-04-07 09843, 2020
outsidecontext
but having the whole family at home all day keeps me busy :D
2020-04-07 09800, 2020
outsidecontext
2FA on Apple is a PITA :( But worked for me this time. But only the account holder can accept the license agreement (which makes sense)
2020-04-07 09807, 2020
ruaok
ah, finally got it.
2020-04-07 09810, 2020
ruaok
any idea where to find the license agreement? nothing shown from the dashboard.
2020-04-07 09805, 2020
ruaok
found it.
2020-04-07 09833, 2020
ruaok
accepted. it would take hours to read that thing. fuckers.
2020-04-07 09820, 2020
outsidecontext
ruaok: thanks, let me check if the notarization runs again
2020-04-07 09810, 2020
outsidecontext
those license agreements are horrible. I guess they mostly count on people accepting without reading. I guess they also did not offer a summary of the changes
2020-04-07 09828, 2020
ruaok
nor would we have a choice if we didn't want to accept.
2020-04-07 09844, 2020
outsidecontext
right
2020-04-07 09841, 2020
outsidecontext
picard notarization is working again :)
2020-04-07 09808, 2020
Mr_Monkey
prabal: I modified `makeEntityLoader` to accept the route '/create' . I'm writing basic tests for the routes now.
2020-04-07 09808, 2020
Mr_Monkey
As for '/create/handler' POST route, we shouldn't need to modify it as the `makeEntityLoader` middleware is only called for GET requests.
2020-04-07 09814, 2020
prabal
Yeah alright :)
2020-04-07 09843, 2020
Mr_Monkey
Thanks for catching the issue, I totally missed it yesterday…
2020-04-07 09822, 2020
prabal
Yeah I missed it too. :( I think test-site should be completed. It has only 4-5 routes rn.
2020-04-07 09826, 2020
prabal
Writing other test for other routes won't be difficult i think...
2020-04-07 09826, 2020
kieto joined the channel
2020-04-07 09856, 2020
Chinmay3199
prabal: Nice suggestion on test-site. I am working on the same
2020-04-07 09818, 2020
ishaanshah[m]
iliekcomputers: Hi, I have updated the docs, added linter to the test suite and made a pre-commit hook
2020-04-07 09826, 2020
ishaanshah[m]
Please have a look
2020-04-07 09828, 2020
iliekcomputers
The pre-commit hook is not installed by default
2020-04-07 09831, 2020
iliekcomputers
Right?
2020-04-07 09832, 2020
ishaanshah[m]
No
2020-04-07 09846, 2020
ishaanshah[m]
I added instructions to the docs
2020-04-07 09843, 2020
iliekcomputers
Right, thanks, that seems reasonable. I'll test today. :)
Reason being we insert the listened_at from 1 to eleven and for full dump we test against listened_at
2020-04-07 09807, 2020
ruaok
well, I just removed that module. screw influx.
2020-04-07 09829, 2020
shivam-kapila
Lol 😂
2020-04-07 09843, 2020
ruaok
ok, why dont you work on the remaining tests for the timescale listenstore and I'll see about fixing the dumpmanager tests?
2020-04-07 09810, 2020
shivam-kapila
ruaok: Sure but I need some help regarding the test I mentioned
2020-04-07 09810, 2020
ruaok
not sure I understand what you are asking/need
2020-04-07 09842, 2020
shivam-kapila
In influx we tested against created rather than listened_at
2020-04-07 09802, 2020
shivam-kapila
for full dumps if I am not wrong
2020-04-07 09837, 2020
ruaok
not sure that is right -- the full dumps don't all have created/inserted_at timestamps, but the incremental ones always will
2020-04-07 09803, 2020
ruaok
so, full dumps should test against listened_at and incremental should test against created
2020-04-07 09858, 2020
shivam-kapila
I ran this test and saw that it fails bkz we have listened_at for test data as 1-11 but for check we pass timestamp value
2020-04-07 09834, 2020
D4RK-PH0ENiX joined the channel
2020-04-07 09843, 2020
shivam-kapila
So 1-11 is always less than the timestamp
2020-04-07 09848, 2020
Zastai
btw while I have you LB folks here. i see LB added MBID importing from last.fm. Is that applied to existing imports? Will a fresh import enrich existing imported listens, or should I reset the "last import" date first?
2020-04-07 09829, 2020
shivam-kapila
But it should split at between. So I just wanted to ask that can I modify the way I generate test data for this test?
2020-04-07 09801, 2020
shivam-kapila
ruaok: ^^
2020-04-07 09833, 2020
ruaok
ah, given that postgres can handle the proper seconds since epoch timestamps, rather than the full long painful influx timestamps, we should move all the tests to not use timestamps, but integer epochs.
2020-04-07 09803, 2020
ruaok
yes, standardize on tests using integer timestamps, not string timestamps.
2020-04-07 09806, 2020
ruaok
does that make sense shivam-kapila?
2020-04-07 09858, 2020
shivam-kapila
ruaok: Didnt quite get it sorry. :(
2020-04-07 09840, 2020
ruaok
ok, influx has one format of timestamps, a longer one that is based on ascii, strings, right?
2020-04-07 09850, 2020
shivam-kapila
Yes
2020-04-07 09811, 2020
ruaok
and the listened_at column in the listens table is an integer, right?
2020-04-07 09817, 2020
shivam-kapila
Yes
2020-04-07 09815, 2020
ruaok
so, now we have 2 formats for timestamps, which is odd. we could adapt the tests to use integer or string, depending on the test.
2020-04-07 09846, 2020
ruaok
OR we could change the created column to also be an integer column.
2020-04-07 09858, 2020
ruaok
that means we we have more consistency in our tables.
2020-04-07 09811, 2020
ruaok
iliekcomputers: any thoughts on this?
2020-04-07 09812, 2020
shivam-kapila
Currently what I modified yestereday is that I assumed we always get datetime type values for start and end times for dumps
2020-04-07 09812, 2020
shivam-kapila
For full dumps we use listened_at so I coverted it to int in listenstore and not in tests
2020-04-07 09812, 2020
shivam-kapila
For incremental we use created_at which is datetime so I pass the values as it is
2020-04-07 09858, 2020
ruaok
I think it might be best for us to keep the schema as is, and then do the necessary conversion between the two formats as needed.
2020-04-07 09821, 2020
shivam-kapila
The current problem I faced is that I input 1-11 in listened_at. I need to form dump values for 1-5 so I need to split it at 5 but for check value I send timestamp value. As its full dump so the timestamp gets converted to integer in the listenstore and as its in millions so 1-11 are all less than thst this millions int. So all get into dump. Did you get it now?
