[mayhem](https://matrix.to/#/@mayhem:chatbrainz.org): iirc you were running into issues with python's GIL in the early stages of building the new LB mapper, right? if so, python 3.14 just dropped and [now officially supports free-threading, i.e., GIL-free](https://docs.python.org/3/whatsnew/3.14…
2025-10-08 28138, 2025
Toasty joined the channel
2025-10-08 28147, 2025
mayhem[m]
yeah, there is only one teeeny little problem they don't talk about... all the libraries that your python project depends on, they too need to be free-running enabled. and for the massive number of libs I need for this project, not going to happen anytime soon.
2025-10-08 28117, 2025
yvanzo[m]
bitmap, reosarevok: Hi!
2025-10-08 28143, 2025
bitmap[m]
hello
2025-10-08 28134, 2025
reosarevok[m]
Hi!
2025-10-08 28154, 2025
yvanzo[m]
I saw you updated a PR about having different test DBs.
2025-10-08 28121, 2025
bitmap[m]
MTCaptcha was successfully deployed to beta yesterday
2025-10-08 28133, 2025
yvanzo[m]
That reminded me of the issue we do have with DBDefs for different use cases.
2025-10-08 28139, 2025
bitmap[m]
yep, I spent quite a bit of time rebasing and fixing test failures in a few PRs
We also did forget we had to update the beta DBDefs for Russian and MTCaptcha, but we did that soon after release and just rereleased :)
2025-10-08 28123, 2025
yvanzo[m]
But it is difficult to use and keep up-to-date for mirrors that have local settings.
2025-10-08 28149, 2025
yvanzo[m]
Similarly, it is difficult to use and keep up-to-date for development setup that have local settings.
2025-10-08 28130, 2025
yvanzo[m]
It would be great to come with default settings for the most common use cases.
2025-10-08 28146, 2025
yvanzo[m]
We currently have only one file DBDefs/Default.pm.
2025-10-08 28127, 2025
yvanzo[m]
I don’t have an exact plan for how to implement it, but here is one proposition: Have alternative FooDefault.pm and allow selecting the initial set of default settings through environment/options.
2025-10-08 28114, 2025
yvanzo[m]
(It would still allow overwriting some settings through a local DBDefs.pm.)
2025-10-08 28114, 2025
bitmap[m]
that is probably the most logical way to do it with our current system. but it would be ideal to switch to a different config file format in the future which would allow for rewriting the config automatically
2025-10-08 28142, 2025
yvanzo[m]
Yes but that wouldn’t be deployable quickly as it would be a breaking change and would take much more time too.
2025-10-08 28107, 2025
bitmap[m]
anyway having separate defaults files for common environments makes sense to me
2025-10-08 28159, 2025
bitmap[m]
at least with them being in perl you can use extends to only override what's necessary
Okay, just to conclude the first topic, I can try to implement it for mirrors, and then we can look together about doing the same for other use cases (test-database, tests, development…)
2025-10-08 28103, 2025
reosarevok[m]
If you're up for that, I don't see why not
2025-10-08 28102, 2025
bitmap[m]
reosarevok[m]: the request to return the browsed events in the response deserves some discussion, perhaps we can do that on the ticket for now though
2025-10-08 28126, 2025
reosarevok[m]
Oh, ok, so I was wondering if I was getting it right
2025-10-08 28157, 2025
reosarevok[m]
So their point is that if you have an event MBID from whatever source they want to be able to get that event and related ones in one go?
2025-10-08 28100, 2025
reosarevok[m]
That seems sensible to me
2025-10-08 28139, 2025
bitmap[m]
yes but it's essentially implementing MBS-6459 too, which I'm not sure makes sense via the browse endpoint. maybe it does, but we are already breaking the definition of "browse"
Like, it makes some sense that browsing events by event would load all the events related to that event, and it's hard to argue that the event itself is not related to it :)
2025-10-08 28149, 2025
bitmap[m]
per the WS documentation: "Browse requests are a direct lookup of all the entities directly linked to another entity ("directly linked" here meaning it does not include entities linked by a relationship)."
2025-10-08 28109, 2025
reosarevok[m]
I mean, events are not directly linked anyway so that's already not true, right
2025-10-08 28118, 2025
reosarevok[m]
So, there's two things here: it seems useful to get an event and all related events recursively, and it seems useful to get multiple events in one API call
2025-10-08 28139, 2025
bitmap[m]
that's my point, the current implementation is already at odds with the original design intention of the web service (although there was already another browse endpoint that used relationships IIRC)
2025-10-08 28113, 2025
reosarevok[m]
I mean, I think that was thought out before we realized that for example recordings are unrelated to works entirely unless we use rels :)
2025-10-08 28119, 2025
reosarevok[m]
(and so are artists)
2025-10-08 28140, 2025
reosarevok[m]
So if we strictly followed that browse would seem to be pretty useless for several use cases
2025-10-08 28119, 2025
reosarevok[m]
I suspect the "directly linked" thing is actually not obvious to anyone really?
2025-10-08 28141, 2025
reosarevok[m]
I think most people see relationship links and the area for an artist or whatnot as basically the same thing 🤷♂️
2025-10-08 28117, 2025
bitmap[m]
I'm in favor of changing the documentation, though I think there's still a question about whether it really makes sense for this to be the solution to MBS-6459
it feels like a hack and not in the spirit of what browse requests are intended for
2025-10-08 28132, 2025
yvanzo[m]
The WS was likely designed with arbitrary limitations to be resilient against bad usage too.
2025-10-08 28159, 2025
reosarevok[m]
I think it makes sense that a browse can return the entire event structure, including the event itself
2025-10-08 28100, 2025
yvanzo[m]
There is nothing engraved in stone but providing a service that is sustainable.
2025-10-08 28125, 2025
reosarevok[m]
If we are already doing that, I think there's no need to do multiple in one call?
2025-10-08 28136, 2025
reosarevok[m]
(I mean, it's an interesting use case, but by then it seems entirely unrelated)
2025-10-08 28100, 2025
yvanzo[m]
So I don’t mind whether the entities are linked directly or not, what is important is the time/resources it takes.
2025-10-08 28126, 2025
reosarevok[m]
So if your suggestion is "drop multiple for now, and just implement one event + containment", I think that's fine and ideally we'd return that event itself as well
2025-10-08 28132, 2025
reosarevok[m]
Does that make sense re: your question?
2025-10-08 28145, 2025
reosarevok[m]
Assuming, as yvanzo says, that it doesn't cause issues, but I understand that it's limited
reosarevok: I think that sounds fine. it doesn't help with sanojjonas's use case still but it sounds like we'd want to implement MBS-6459 differently later on
"now there are cases where i already got something but then have to refetch the same thing again. for example when i browse events from a collection. in that case i don't get the linked stuff. so then i have to refetch something that is already sorted. i also already know the child events, so if i could multi fetch the child events then it would be solved."
2025-10-08 28127, 2025
reosarevok[m]
To some degree at least
2025-10-08 28142, 2025
reosarevok[m]
In the sense that we can fetch once more and get all
2025-10-08 28142, 2025
bitmap[m]
the problem is if you want to lookup multiple events and include all of the sub-events for them
2025-10-08 28107, 2025
reosarevok[m]
Yeah, understood, but I think one step at a time makes sense :)
2025-10-08 28124, 2025
yvanzo[m]
Can we provide a count or something that make it easier for them to know if they must make additional queries?
2025-10-08 28125, 2025
reosarevok[m]
Now you get all levels rather than one so it potentially saves a lot of calls
2025-10-08 28137, 2025
yvanzo[m]
(Like a count of sub-events?)
2025-10-08 28153, 2025
bitmap[m]
reosarevok[m]: I'm mentioning it because dropping support for multiple parameters is at odds with that
2025-10-08 28100, 2025
reosarevok[m]
I get that
2025-10-08 28105, 2025
zer0bitz-_ joined the channel
2025-10-08 28113, 2025
reosarevok[m]
But your implementation without multiple parameters already fulfills MBS-13963 itself
bitmap: I was asking: if I browse events by an event, and that event has 200 sub-events, will it give me count: 200, offset: 0, show the first X events and let me offset to get the rest?
2025-10-08 28145, 2025
bitmap[m]
yes
2025-10-08 28112, 2025
reosarevok[m]
Ok, then that seems good - what is the count that is missing? :)
2025-10-08 28113, 2025
bitmap[m]
note that it returns linked events in either direction (so also returns parent events)
If it does make it easier for them to use the API, and doesn’t impact the API performances too much.
2025-10-08 28137, 2025
bitmap[m]
reosarevok: yvanzo is saying that if you have an individual event (from wherever), it's not clear whether you need to retrieve sub-events for it
2025-10-08 28117, 2025
reosarevok[m]
Oh. Well, that seems like a further improvement that could be done later, but we could add it if trivial enough :)
2025-10-08 28109, 2025
reosarevok[m]
It does seem like it'd help avoid wasted calls, so why not
2025-10-08 28152, 2025
yvanzo[m]
It would probably require to cache these counts if not cached already.
2025-10-08 28144, 2025
bitmap[m]
also requires an mmd-schema change unless we only implement it for the JSON WS, but
2025-10-08 28112, 2025
yvanzo[m]
correct
2025-10-08 28138, 2025
yvanzo[m]
So it should be a separate ticket if planned.
2025-10-08 28139, 2025
yvanzo[m]
bitmap: Is it enough to keep making progress with this topic?
2025-10-08 28129, 2025
reosarevok[m]
So, I'd suggest for now add a ticket for that count, consider reverting the multi-browse if you don't feel confident about it for now (but keep the code, maybe even open a draft PR for further discussion)
2025-10-08 28118, 2025
reosarevok[m]
Consider whether it makes sense to also show the event itself (if not that's at most one extra call though so not the end of the world)
2025-10-08 28136, 2025
reosarevok[m]
(can also be a future discussion / improvement if needed)
2025-10-08 28146, 2025
reosarevok[m]
Does that sound about right? :)
2025-10-08 28132, 2025
bitmap[m]
I'm still unsure about the design questions but it's enough discussion for today at least
2025-10-08 28159, 2025
bitmap[m]
for now I'll just revert the multi-browse stuff and have it return the browsed event in the response, since that seems more useful than not
2025-10-08 28128, 2025
reosarevok[m]
Seems good, we can have a discussion about multi-stuff more generally soon since that seems useful for most entities :)
