+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: Req Postgres Support (/showthread.php?tid=143955)
Pages:
1
2
Postgres Support - ZitZ - 2012-10-30
Many people don't like the direction Oracle takes with MySQL, so it would be nice to have the ability to use Postgres as a backend to sync the library in addition to MySQL.
RE: Postgres Support - jmarshall - 2012-10-30
No. MySQL support will likely be removed as well eventually.
RE: Postgres Support - da-anda - 2012-10-30
"eventually" means once have some kind of client/server thingy
RE: Postgres Support - ZitZ - 2012-10-30
So the plan is to have "built-in" client/server support, which I suppose would make use of the sqlite db on the server?
What is the advantage to this as opposed to having a dedicated backend database such as MySQL/Postgres?
RE: Postgres Support - Montellese - 2012-10-30
Easier setup, no additional network delay on every SQL query, only having to support a single database engine, the possibility to move away from SQL ...
RE: Postgres Support - ZitZ - 2012-10-30
I appreciate and agree with all those reasons.
Except for the last, I feel right now that "NoSQL" is hip and everyone wants to move away from SQL because it is the cool thing to do. Honestly, I love the "old fashioned" reliable databases to store my data, they have decades of reliability, whereas the newcomers have yet to prove themselves in terms of reliability and have yet to show any obvious benefits, atleast to me.
RE: Postgres Support - Montellese - 2012-10-30
I didn't mention NoSQL. There are other alternatives. And it's only the possibility. The more backends we rely on the more difficult it is to get away from them.
RE: Postgres Support - Robotica - 2012-10-31
sorry for this dumb question but what is the plan
RE: Postgres Support - topfs2 - 2012-10-31
(2012-10-30, 22:09)ZitZ Wrote: I appreciate and agree with all those reasons.
Except for the last, I feel right now that "NoSQL" is hip and everyone wants to move away from SQL because it is the cool thing to do. Honestly, I love the "old fashioned" reliable databases to store my data, they have decades of reliability, whereas the newcomers have yet to prove themselves in terms of reliability and have yet to show any obvious benefits, atleast to me.
Problem with media is if you want to store an arbitrary and dynamic set of metadata, which you want when you scrape. Music has a vastly different set of metadata than Movies. Or more closely, Movies and Home videos have a serperate set of metadata. And when we consider linking between all these items it gets out of hand real quickly, any type can essentially link to any other (which I guess you might be able to solve by using simply one column for any link(s), but then you need to do recursive lookups to deduce what it links to).
With a traditional SQL based database you essential have two choices (atleast afaik) to deal with these differences in a unifying way. a) You make one table for each type or b) you implement a key value database where one column is key and another is value.
If we look at a) this makes us locked down, and we can only add media types on releases (or rely on plugins for the datastransaction). If we do b) thats essentially what a NoSQL is, and is infact how SPARQL is implemented ontop of SQL.
IMO the only way forward for XBMC is to go with b), either using a NoSQL db like couchdb, mongodb or sparql. Or simply do it ourself with a key value store (which there is a pull request for, atleast the database abstractions).
Cheers,
Tobias
RE: Postgres Support - ZitZ - 2012-10-31
Cool. Well thanks for the information everyone. I'm an interested user and part time developer, so it's nice to gain insight from the development team of this wonderful project. So please understand that I'm not trying to debate anyone.
I understand that relying on a backend decreases the flexibility of your project, but I thought the linux philosophy was to be modular in the fact that multiple projects could use the same library on the machine, and even the same database service, so multiple programs (e.g. XBMC, Owncloud) could make use of the same backend database.
RE: Postgres Support - jmarshall - 2012-10-31
We have no problem being modular. The point is we don't want to maintain db-specific wrappers. The mysql stuff has caused a whole heap of grief because SQL is simply not portable, and without testing across multiple servers things can and can and will break.
I suspect we'll end up using something similar to https://github.com/xbmc/xbmc/pull/1562
i.e. a metadata store implemented on top of SQL.
Cheers,
Jonathan
RE: Postgres Support - topfs2 - 2012-11-01
Ah, thats the pull request I mentioned. Thanks for digging it up
As another reference I'll state that redland, or librdf, (sparql implementation) is able to be stored in sqlite, mysql and postgres. Its even able to fallback to filestorage. It may be another direction we could go if we don't want to maintain the metadata store and query ourselfs. (I have noted this in the pull request aswell)
RE: Postgresql Support - Tuju - 2013-03-11
I ported:
http://wiki.xbmc.org/index.php?title=Database_Schema_4.0/a
to Postgresql:
http://tuju.fi/projects/xbmc/
create a database and:
$ psql xbmc < schema.psql
What files should be implemented? Dir xbmc.git/xbmc/dbwrappers has:
Code:
Database.cpp dataset.cpp Makefile mysqldataset.h qry_dat.h sqlitedataset.h
Database.h dataset.h mysqldataset.cpp qry_dat.cpp sqlitedataset.cppmysql code looks way much bigger than sqlite code, does sqlite implement enough features?
RE: Postgres Support - spiff - 2013-03-11
sqlite is the target db, everything else is hacks. you have to implement those wrapper classes for postgres.
don't expect it to be accepted in mainline.
RE: Postgres Support - Tuju - 2013-03-11
(2013-03-11, 11:55)spiff Wrote: sqlite is the target db, everything else is hacks. you have to implement those wrapper classes for postgres.
sqlite doesn't provide network socket and thus cannot share same data between different terminals.
Quote:don't expect it to be accepted in mainline.
ack. I can keep it in small circle, no problem with that.
From IRC:
Quote:basically, you have to implement the dataset class, and the fluff around it in the CDatabase class
ack.