[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-androi…
2024-09-11 25515, 2024
BrainzGit
[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-androi…
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
2024-09-11 25523, 2024
relaxo[m]
add the id?
2024-09-11 25547, 2024
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.
2024-09-11 25509, 2024
lucifer[m]1
if we want to exclude those i think we should instead use payment date ranges for pagination.
2024-09-11 25549, 2024
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"
2024-09-11 25501, 2024
reosarevok[m]
(or whatever other)
2024-09-11 25533, 2024
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?
2024-09-11 25544, 2024
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
2024-09-11 25509, 2024
reosarevok[m]
I guess technically we could give MBIDs to relationships, but that's unlikely to happen anytime soon...
2024-09-11 25534, 2024
reosarevok[m]
How often does this sort of case actually happens? :)
2024-09-11 25524, 2024
reosarevok[m]
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?
2024-09-11 25554, 2024
reosarevok[m]
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?
2024-09-11 25518, 2024
reosarevok[m]
(otherwise that'd be the simplest)
2024-09-11 25528, 2024
relaxo[m]
Exactly, the rowid of the relationship... Oh damn...... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/fMsYzcZOoZcHShoLnrxpMfWT>)
2024-09-11 25500, 2024
reosarevok[m]
I mean, as a user I think if the time changes like that:
2024-09-11 25533, 2024
reosarevok[m]
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
2024-09-11 25504, 2024
reosarevok[m]
b) is after the concert, then there was a mistake in the data and I should probably review that I marked myself correctly
2024-09-11 25518, 2024
reosarevok[m]
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 😅
2024-09-11 25529, 2024
reosarevok[m]
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
2024-09-11 25557, 2024
reosarevok[m]
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
2024-09-11 25534, 2024
reosarevok[m]
Just thought I'd mention it since I'm not sure how you build the stuff :)
2024-09-11 25551, 2024
relaxo[m]
I think it is okay when have nice texts for the user for a) b) and c).
2024-09-11 25511, 2024
relaxo[m]
And no, I don't want to scrape the id from a button :D
2024-09-11 25517, 2024
relaxo[m]
At least it will spare me a db schema change in the app, just have to implement the smart matching and dialogs/notifications.
2024-09-11 25530, 2024
q3lont joined the channel
2024-09-11 25553, 2024
reosarevok[m]
Yeah, I think telling the user "hey, something weird happened, please take a look" is sensible for edge cases like these :)
2024-09-11 25531, 2024
reosarevok[m]
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
2024-09-11 25540, 2024
relaxo[m]
I would put this on the far bottom of my list of wanted features.
2024-09-11 25559, 2024
reosarevok[m]
Yeah, suspected so
2024-09-11 25508, 2024
reosarevok[m]
What's on top? :D
2024-09-11 25514, 2024
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
2024-09-11 25511, 2024
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)
2024-09-11 25539, 2024
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
2024-09-11 25529, 2024
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 😶)
2024-09-11 25519, 2024
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.
2024-09-11 25528, 2024
lucifer[m]1
thoughts?
2024-09-11 25521, 2024
reosarevok[m]
Is the flair something the user enters, or chosen from a list of accepted flairs?
2024-09-11 25550, 2024
lucifer[m]1
i think the latter.
2024-09-11 25555, 2024
reosarevok[m]
If the former (text flair) I'd say user table, if the latter settings or a separate user_flair table or whatnot
2024-09-11 25548, 2024
reosarevok[m]
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.
2024-09-11 25500, 2024
lucifer[m]1
mayhem: also, we should count the fee in the amount when checking for tiers?
2024-09-11 25519, 2024
mayhem[m]
no, we should only consider the gross amount.
2024-09-11 25541, 2024
lucifer[m]1
right we don't store the gross amount i think. only net amount and fee separately
2024-09-11 25558, 2024
mayhem[m]
ah, in this case net == gross.
2024-09-11 25509, 2024
mayhem[m]
actually, lets check.
2024-09-11 25536, 2024
mayhem[m]
there are three possible values: $10, $.43 and $9.57.
2024-09-11 25546, 2024
mayhem[m]
we should always work with what left the user's walled, so $10.
2024-09-11 25528, 2024
lucifer[m]1
cool, that's what i am aiming for as well.
2024-09-11 25520, 2024
lucifer[m]1
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.
2024-09-11 25530, 2024
lucifer[m]1
when entering manually.
2024-09-11 25546, 2024
mayhem[m]
only because I've never been smart enough to have thought of that.
2024-09-11 25552, 2024
lucifer[m]1
for LB, we'll have it prefilled anyway.
2024-09-11 25510, 2024
lucifer[m]1
well no need to ask the user just get it from the cookie.
