[listenbrainz-android] 14dependabot[bot] opened pull request #484 (03dev…dependabot/gradle/dev/com.google.devtools.ksp-2.0.20-1.0.25): Bump com.google.devtools.ksp from 2.0.0-1.0.23 to 2.0.20-1.0.25 https://github.com/metabrainz/listenbrainz-andr...
[listenbrainz-android] 14dependabot[bot] closed pull request #479 (03dev…dependabot/gradle/dev/com.google.devtools.ksp-2.0.20-1.0.24): Bump com.google.devtools.ksp from 2.0.0-1.0.23 to 2.0.20-1.0.24 https://github.com/metabrainz/listenbrainz-andr...
reosarevok hey, you are the one who has implemeted my request to allow multiple relations to the same artist when time or artistCredit is different, right? I hace problems now while using the api, because i can not update relations because i missed adding the relation/link id to my DB schema. Now I looked into how to solve it and figured out, that the relation ID is not included in the api response. Ist that correct? Is it possible to
add the id?
lucifer[m]1
mayhem: for the donors endpoints, there will be some donations made by non-LB users. should the endpoint include or exclude those? excluding those makes it harder to paginate with count and offset.
if we want to exclude those i think we should instead use payment date ranges for pagination.
mayhem[m]
include. because that way when MB donating people come to LB, they can already see their flair.
Are you looking for the relationship type row id? Because the type's MBID is there, "936c7c95-3156-3889-a062-8a0cd57f8946"
(or whatever other)
relaxo[m]
The rel type row id is the same on each rel. I have to distinguish the artist rels. In example, We have one artist performing on one event to multiple times. When the time of one performance changes, then I have to identify that exact rel in my database to update it. In my thinking, this is only possible when I have the id of the l_artist_event table. Or how to you update/edit the rel?
reosarevok[m]
Ah. So you want the specific rowid for the relationship. Honestly, that starts to be the point where you should be using the DB, not the API... we don't expose rowids for anything in the API
I guess technically we could give MBIDs to relationships, but that's unlikely to happen anytime soon...
How often does this sort of case actually happens? :)
It seems to me you should either just have one performance, in which case if it changes time you just change it, or you have several, in which case if one changes time the other hasn't so you know which one to change, or you have several which all change and at that time does it matter which was which originally?
I'm expecting the reason you don't just remove the ones no longer there and readd new ones is that you have a way for users to say they're attending a specific performance or whatnot so it's relevant not to break that?
I mean, as a user I think if the time changes like that:
a) it's before the concert, then I should be notified of the problem anyway since it might mess up my plans for the concert
b) is after the concert, then there was a mistake in the data and I should probably review that I marked myself correctly
c) is after the concert, the artist was listed once earlier without time and now there's multiple timed options, I probably need to say which one I want 😅
If you have the ID already and you really want to check in a rare case, the relationship id is exposed on the remove relationship button ID in the relationship editor for the event
But I guess the problem is you don't have the IDs yet anyway if you're building the thing through the API and not the DB, so that's probably not of great use
Just thought I'd mention it since I'm not sure how you build the stuff :)
relaxo[m]
I think it is okay when have nice texts for the user for a) b) and c).
And no, I don't want to scrape the id from a button :D
At least it will spare me a db schema change in the app, just have to implement the smart matching and dialogs/notifications.
q3lont joined the channel
reosarevok[m]
Yeah, I think telling the user "hey, something weird happened, please take a look" is sensible for edge cases like these :)
That said, we've added MBIDs to more and more things, so never say never about them being added to specific relationships too eventually 😅 just not in the plans rn
relaxo[m]
I would put this on the far bottom of my list of wanted features.
reosarevok[m]
Yeah, suspected so
What's on top? :D
discordbrainz
<05rustynova> What you could do is to wipe all the relations of the event in your DB and replace it with the updated ones. Then, if you want, you can check for the difference between the old data and new data by comparing the time value of the relationship, so you can see when a time was added/removed
relaxo[m]
Getting an event and all sub (...sub...sub....) events in one request (To avoid loading time of one minute for one event due to the 1sec rate limit) and include sub areas/places in event search (To enable the user to search for an event in an area)
discordbrainz
<05rustynova> I did that for storing Listenbrainz data. Each API call wipe a bit of the database and replace it with the fresh data. If there was a row ID it would have been easier but alas
relaxo[m]
@rustynova Yeah will do that but i update instead of wiping. But there will be some cases where the user hast do manually check/decide to update or not like mentioned above.
(shh, noone mention this is about the part of the whole setup I have the least to do with 😶)
lucifer[m]1
mayhem: i am divided on wheteher to store user flair in settings or user table. it does feel like a setting but in general we don't expose a user's settings to other users so also feels like something that should go into the user table.
thoughts?
reosarevok[m]
Is the flair something the user enters, or chosen from a list of accepted flairs?
lucifer[m]1
i think the latter.
reosarevok[m]
If the former (text flair) I'd say user table, if the latter settings or a separate user_flair table or whatnot
In MB for example the editor_preference table would seem a good fit, because it specifies what is shown to others in the same way as, say, public_ratings
mayhem: one more thing, some donations are in EUR, others in USD. we can display the currency with the amount but for the purpose of any ordering or tiers etc we assume 1 USD = 1 EUR
yea, seems ok. that logic works for the US banks, we can get away with such sloppy shit on our leaderboard page.
lucifer[m]1
mayhem: also, we should count the fee in the amount when checking for tiers?
mayhem[m]
no, we should only consider the gross amount.
lucifer[m]1
right we don't store the gross amount i think. only net amount and fee separately
mayhem[m]
ah, in this case net == gross.
actually, lets check.
there are three possible values: $10, $.43 and $9.57.
we should always work with what left the user's walled, so $10.
lucifer[m]1
cool, that's what i am aiming for as well.
mayhem: and for donation forms on MeB page, is there a reason why the donation form isn't prefilled with the editor's name if logged in? a lot of people in the database seem to have made typos there.
when entering manually.
mayhem[m]
only because I've never been smart enough to have thought of that.
lucifer[m]1
for LB, we'll have it prefilled anyway.
well no need to ask the user just get it from the cookie.
