ODBC (Open Database Connectivity) database abstraction layer or API for XBMC?
#31
It's actually smarter to have all media information in one database, and then have a single table that associates the individual profile with each media item (listed as "direntry" in the schema). That way you're not duplicating information and it's really simple to manage and perform cross-profile queries. It also easily handles things that cross profile boundaries.
Reply
#32
wstewart Wrote:But I think the main problem with ODBC is finding database drivers for OS-X and Windows that don't cost anything


Drivers and source is on this page...
http://dev.mysql.com/downloads/connector/odbc/5.1.html
Reply
#33
szsori Wrote:It's actually smarter to have all media information in one database, and then have a single table that associates the individual profile with each media item (listed as "direntry" in the schema). That way you're not duplicating information and it's really simple to manage and perform cross-profile queries. It also easily handles things that cross profile boundaries.

That is true but it seems to be a much deeper change in the overall database structure XBMC is using. I think for the ODBC/centralized feature it would be best to just focus on ODBC integration while keeping everything else intact. Effectively this would mean adding ODBC to the database class and adding an overwrite to point to a shared folder that contains thumbs etc.

Later a change like that could be done and then applied to both sqlite and ODBC.
Reply
#34
Still don't get that you merely want to create a database for XBMC. Where is the abstraction? I do not believe the database level should matter at all. The abstraction should occur at the API level (however that is implemented).

What if you wanted to store the actual information in some distributed fashion and use an object broker. This ODBC stuff is way outdated.

ODBC or no ODBC should not matter. Nobody but UMM should read the information directly, regardless of its origins. Indeed, the UMM API may very well be a realtime aggregator.

I thought that was something we agreed on but apparently not so.
Reply
#35
rernst Wrote:Still don't get that you merely want to create a database for XBMC. Where is the abstraction? I do not believe the database level should matter at all. The abstraction should occur at the API level (however that is implemented).

What if you wanted to store the actual information in some distributed fashion and use an object broker. This ODBC stuff is way outdated.

ODBC or no ODBC should not matter. Nobody but UMM should read the information directly, regardless of its origins. Indeed, the UMM API may very well be a realtime aggregator.

I thought that was something we agreed on but apparently not so.

I don't believe we're in the UMM forum, are we? Beyond that, database abstration is a good thing whether it's handled in XBMC or outside in UMM. If done in XBMC, then XBMC can easily connect to UMM's database directly. I think trying to complicate it by making an API between the systems is far more complex (and unnecessary) than just allowing XBMC to directly interface UMM.

As for the XBMC developers, they haven't officially supported any type of database move to UMM nor do I expect they would. More likely is that they'd support it as another type of source the same as a UPnP server. That would still allow XBMC to function on its own without needing UMM, but would still allow the power that a system like UMM could bring.

In a nutshell, ODBC (or similar) is a good thing and can help with the UMM stuff at some point (direct interaction with UMM without needing an API). Additionally, UMM is far from being a reality and XBMC development shouldn't be adjusted to account for something that doesn't exist yet.

ccMatrix Wrote:That is true but it seems to be a much deeper change in the overall database structure XBMC is using. I think for the ODBC/centralized feature it would be best to just focus on ODBC integration while keeping everything else intact. Effectively this would mean adding ODBC to the database class and adding an overwrite to point to a shared folder that contains thumbs etc.

Later a change like that could be done and then applied to both sqlite and ODBC.

jmarshall is making some pretty significant changes to the library anyway. If those changes are actually implemented, it would probably be smart to do it "the right way" the first time around. Smile
Reply
#36
szsori Wrote:I don't believe we're in the UMM forum, are we?
No this is the XBMC Feature Suggestions Forum and the discussion is about implementing database abstraction into XBMC itself Wink

Ability to share and synchronize XBMC userdata profiles between multiple machines and the possibility of having a XBMC "Server" - centralized XBMC management for multiple XBMC devices/platforms or feature like "Follow Me", save bookmark/playlist on one XBMC machine and then resume on a other iare just a few of the reasons why people want this database abstraction in XBMC itself.

Something like a networked Unified Media Manager (UMM) is also a thing that might be able to take advantage of a such database abstraction in XBMC if implemented, but that is not directly what this discussion is about.
Reply
#37
rernst Wrote:Still don't get that you merely want to create a database for XBMC. Where is the abstraction? I do not believe the database level should matter at all. The abstraction should occur at the API level (however that is implemented).

What if you wanted to store the actual information in some distributed fashion and use an object broker. This ODBC stuff is way outdated.

ODBC or no ODBC should not matter. Nobody but UMM should read the information directly, regardless of its origins. Indeed, the UMM API may very well be a realtime aggregator.

I thought that was something we agreed on but apparently not so.

Yeah that makes sense to me. ODBC (JDBC etc) is just a connectivity protocol, and do not per se enable any abstraction layer. ADOdb (esp for Python) like Gamster17 posted, and OpenDBX are proper open abstraction APIs.
Reply
#38
Soju Wrote:Yeah that makes sense to me. ODBC (JDBC etc) is just a connectivity protocol, and do not per se enable any abstraction layer. ADOdb (esp for Python) like Gamster17 posted, and OpenDBX are proper open abstraction APIs.

The idea behind this is to use a technology like ODBC to allow an advanced user to let XBMC connect to pretty much any SQL based database he has setup. Thereby he can use a central server to store the database for several XBMC installations in the house and they are automatically in sync since they use the same database.

Currently the main discussion should be about which technology to use. AFAIK ADOdb is not platform independent so while it might be considered to provide database access to the integrated WebServer (see previous discussion) it isn't a very good candidate for this endeavor.

OpenDBX currently also seems to be Unix/Linux/OS-X solution. Real native Windows support is still missing so it might be an alternative in the future but isn't currently an option - except if someone wants to add Windows support and then integrate it into XBMC.
Reply
#39
ccMatrix Wrote:The idea behind this is to use a technology like ODBC to allow an advanced user to let XBMC connect to pretty much any SQL based database he has setup.

I agree. But ODBC is not per se an abstraction layer. It allows for an ODBC socket transactions. There are other things that databases do that ODBC in and of itself will not accomplish. Plus it's an aging protocol that is rather latency sensitive (I should know, started out as a DBA on Keyfile, Sqlserver 7 and Oracle 8 Wink). Typically:

Application --> ADO --> ODBC --> Database

Quote: Thereby he can use a central server to store the database for several XBMC installations in the house and they are automatically in sync since they use the same database.

Thats great but that's the back end... which can be virtually anything. My feelings are that you should have multiple ways of accessing the XBMC suite. There are already great, well developed APIs (e.g., HTTP-API), having the right levels of abstraction built in will allow for rapid prototyping minimally. I would think at this stage flexibility is essential. Developing a framework is key, not hardcoding any sort of quickfix.

Quote: AFAIK ADOdb is not platform independent so while it might be considered to provide database access to the integrated WebServer (see previous discussion) it isn't a very good candidate for this endeavor.

It's true not everything will run of Windows well, especially on all versions of Windows. That said, if Oracle can hook up to it, so can all the others on the list.

Quote:OpenDBX currently also seems to be Unix/Linux/OS-X solution. Real native Windows support is still missing so it might be an alternative in the future but isn't currently an option - except if someone wants to add Windows support and then integrate it into XBMC.

What do you mean by real native support? We don't have OSS kernel hackers in Windows you know. OpenGL and X both run well on windows, and still by MS standards they are not "native". Here is a OpenDBX statement on the matter:

Starting with release 1.3.10, the Windows platform is supported via the Cygwin or MinGW environments. Since version 1.3.11, the applications in "utils/" directory are built by default. If you want to leave this out of the build process, you can disable compilation... The steps to build the OpenDBX library are the same as in the Unix environment.

MinGW is a "native" port of GNU to windows. Cygwin is more "emulated" but no less functional IMHO. You can just about script anything in windows with the latter *nix style.

BTW, what do people think of Apache Derby RDBMS? Yes it's Java based but it's pretty light weight and comes embedded.
Reply
#40
Heres an interesting discussion. Whats not mentioned is the variability and scalability encountered when you sink an embedded db and a server. Locking contentions and replication, among many other factors are important. If you want to dictate one back end DBMS like mySQL or pgSQL then it's a no brainer to just implement ODBC and code up the necessary hooks, calls and lookups etc. But if flexibility to integrate different DBMS architectures are goals then you are right, something like ADOdb is the very way to go. I'm looking at OpenDBX for a work project, it'll probably be faster than ADOdb for somethings, but not sure it will add anything other than performance to the mix.
Reply
#41
I'm looking at LibDBI and OpenDBX and I am liking them so far. They look very interesting, I think they may be a bit easier to use than ODBC and I think a lot less code modification to adapt XBMC to it.

OpenDBX has drivers for postgres, mysql and sqlite. Would not need to use a manager like in ODBC, could put the server ip/username/password directly in XBMC as settings from GUI since these are passed as parameters to the api routine to initialize the db connection. The same API can be used for sqlite, for the existing xbmc database implementation, when opening the connection you give it the location and name of the database file instead of the ip/username.

I have to look a little more closely at the windows side, if it is workable. But if we were to embedded the code in XBMC, it is light weight and may work for the XBOX implementation.
Reply
#42
Wow, man, sorry. Yes, I thought I was responding to a UMM post.

szsori Wrote:I don't believe we're in the UMM forum, are we? Beyond that, database abstration is a good thing whether it's handled in XBMC or outside in UMM. If done in XBMC, then XBMC can easily connect to UMM's database directly. I think trying to complicate it by making an API between the systems is far more complex (and unnecessary) than just allowing XBMC to directly interface UMM.

As for the XBMC developers, they haven't officially supported any type of database move to UMM nor do I expect they would. More likely is that they'd support it as another type of source the same as a UPnP server. That would still allow XBMC to function on its own without needing UMM, but would still allow the power that a system like UMM could bring.

In a nutshell, ODBC (or similar) is a good thing and can help with the UMM stuff at some point (direct interaction with UMM without needing an API). Additionally, UMM is far from being a reality and XBMC development shouldn't be adjusted to account for something that doesn't exist yet.



jmarshall is making some pretty significant changes to the library anyway. If those changes are actually implemented, it would probably be smart to do it "the right way" the first time around. Smile
Reply
#43
wstewart Wrote:I'm looking at LibDBI and OpenDBX and I am liking them so far. They look very interesting, I think they may be a bit easier to use than ODBC and I think a lot less code modification to adapt XBMC to it.

OpenDBX has drivers for postgres, mysql and sqlite. Would not need to use a manager like in ODBC, could put the server ip/username/password directly in XBMC as settings from GUI since these are passed as parameters to the api routine to initialize the db connection. The same API can be used for sqlite, for the existing xbmc database implementation, when opening the connection you give it the location and name of the database file instead of the ip/username.

I have to look a little more closely at the windows side, if it is workable. But if we were to embedded the code in XBMC, it is light weight and may work for the XBOX implementation.

Are you thinking of taking a crack at it?
Reply
#44
Soju Wrote:Are you thinking of taking a crack at it?

Yes, but not probably for a month or so, but in the meantime I will be looking over the code and possible solutions (ie. OpenDBX, ODBC) getting ready to code. Just is the process of converting over from mythtv, gotta finish that first, got a big video collection.
Reply
#45
I was just over at sourceforge to vote in the community choice awards, and found the following project:
http://cppdbc.sourceforge.net/

Maybe this could be useful for XBMC?
Reply

Logout Mark Read Team Forum Stats Members Help
ODBC (Open Database Connectivity) database abstraction layer or API for XBMC?2