(2015-11-30, 10:47)Tolriq Wrote: Well the other part of the same sentence maybe : Quote:Microservices remove the database as a coupling device.
.
Your quote, quoted like is was is clear, about what a micro service is and why it should be decoupled from database and that's the reason why 1 database per micro service is bad and scary.
I perfectly understand the quote and this and I also know that Kodi video and audio are clearly not 2 independent microservices.
Anyway the question after your answer is what are the things that are not the same? And what are the friction ?
This thread is a one year thinking around that with response and schema that fit all the know actual and future needs with lots of arguments discussion and thinking.
Throwing it away, with an unrelated quote and no argument is not cool for all the work that was done here.
Please note that I was not involved in this and have no idea if the schema is correct or not, but I do know the amount of work that was done, and maybe the need to some respect for it.
If I would not respect the work I wouldn't have said anything and let this lay around, without discussion.
The schema itself might be fine, but I get a weird feeling, that there has not been that much work/proof, when I (still) find typos in the headers. But thats just a remark and has nothing to do with my point.
As you might know, I wasn't around a year ago and even if I were, I probably wouldn't have been involved in database decissions for Kodi itself.
Also I'm not saying, this is a bad idea, I'm saying consider what this will cause. Both negative and positive.
Things not being the same can be solved by moving all additional data to one generic table. Generic as in much rows not columns. So that's to consider, but not a show stopper, as long as nobody starts to create nullable fields or use fields for usecases that are not in the column name.
Friction will be higher as everybody will have to work with the same database and it might get harder to overview. Also if some addon like emby for example edits your data it will potentially not only break movies/tvshows then, but music also.
(2015-11-30, 11:38)phate89 Wrote: First of all I don't see Razze's intervention as lack of respect. He entered the dev team not a long ago and he's actually entered in the discussion that didn't have a lot of "official" dev opinions..
But I still agree with tolriq. video and audio aren't separated services..
Imho this is one of the main kodi limits. They intersect with each other everywhere.. Movie have soundtracks, music have videoclips, a person could be an actor and a singer etc etc. Of course right now there aren't too many interactions like these in the code so the separation isn't a big problem now but the actual separation makes harder to bring them and will hurt kodi in the future.
The single database is imho more future.-proof. It will make these kinds of changes simpler and reduce the amount of db changes in the future..
I also understand why high scalability with microservices is better in a lot of cases but we're talking a "small", local, almost always single access database... There are less advantages here..
Well that person case is in fact something that should be splitted into an own database in my world. Then both music and video and whatever could use that service/repo.
(2015-11-30, 12:13)Tolriq Wrote: As phate89 says, all depends on what to develop, for bug fixes of course as the database are already split and have different bugs.
But for future things that are asked since long time, like user ratings, user play states this means all have to be done X times with X different implementation since each database is fundamentally different.
Each time adding more difference to each database instead of having common things more efficient and more stable since more thought.
I don't think that the database implementation is our problem here. Like when I added user ratings, for every part music/video, the amount of sql I wrote was like 3% of the changes I guess?