• 1
  • 16
  • 17
  • 18
  • 19
  • 20(current)
New DB Structure for all libraries + DBs [update 2015 06 13 / Released SQL 1.3]
(2016-01-17, 17:49)xnappo Wrote: In Emby for Kodi - we don't take override the DB, we just sync the Emby DB to the Kodi DB. So we are overriding the scraper, not the db. The complexity of the current DB made doing this difficult (mostly the way interrelated items work on the TV side).

Of course we are watching this thread closely because it will be a lot of work for us if the Kodi DB changes Smile

Hopefully it will make your life much easier Smile
If you think I'm useful please use the +/- button to raise my reputation
Reply
(2016-01-18, 20:30)m.savazzi Wrote:
(2016-01-17, 17:49)xnappo Wrote: In Emby for Kodi - we don't take override the DB, we just sync the Emby DB to the Kodi DB. So we are overriding the scraper, not the db. The complexity of the current DB made doing this difficult (mostly the way interrelated items work on the TV side).

Of course we are watching this thread closely because it will be a lot of work for us if the Kodi DB changes Smile

Hopefully it will make your life much easier Smile

Longer term, yes.

Also when we looked into why JSON-RPC was slow we got to the point where it appeared the entanglement of the scraper and DB code was a big part of the problem - so hopefully with this refactor we can fix up JSON-RPC so we aren't being mavericks anymore.

xnappo
Reply
Hello,


Is there any news about this subject?

regards
Reply
waiting as well... Smile
Reply
Hello,

is this subject completely abandonned?

Regards,

Big
Reply
I really hope not...my DB is very large and getting unwieldy.
Reply
devs are currently working on replacing our SQL layer with something object oriented. After this is done, we can think about switching over to a new DB schema.
Reply
Ok,

Thanks for the news

Seems to be logical in that way...

Regards,

Big
Reply
Making the tool before knowing what you want to build may not sound that logical Wink

But at least it's a step forward.
Reply
(2017-07-28, 17:15)Tolriq Wrote: Making the tool before knowing what you want to build may not sound that logical Wink

True, but the DB refactor has to come first. We can't change two things at once, and the current system won't support a large scale schema change. Once the new ORM is in place, it'll be possible to adopt a new schema.

The ODB work has a feature branch in our repo: https://github.com/xbmc/xbmc/tree/feature_odb
Reply
Yes I've seen it already Wink

The main issues actually are tied to the fact that many things are done at Kodi level, and that many things are get via new queries and not on the first one. (Not speaking about the schema of course)

If the target is now known, the tool may in the end not fit those needs and while it will be refactored the target will still be unreachable. And many ORM are not smart about 1-n n-n relationship and needs to be carefully chosen Wink

Knowing the target shows the path. Changing a shovel for a bulldozer looks cool, but in some cases the bulldozer can't pass between the houses Wink

Disclaimer I have not actually checked what ODB offers and hope it will be the right tool.
Reply
  • 1
  • 16
  • 17
  • 18
  • 19
  • 20(current)

Logout Mark Read Team Forum Stats Members Help
New DB Structure for all libraries + DBs [update 2015 06 13 / Released SQL 1.3]3