2009-07-27, 23:17
CapnBry Wrote:Notably missing:
-- Retrieving result values in native types (every value is char *)
-- Parameterized queries
Retrieving values in native types can be wrapped quite easily, whilst every "value" is a char* the column type (ie. INT, BOOL, etc) is also available to facilitate the conversion.
Yes parameterized queries would be nice to have though not essential since, for the reason you mention, dbiplus doesn't have it either. "escape the SQL" will have to linger a bit longer.
CapnBry Wrote:Again I will also bring up the fact that SQL itself is the tricky bit. How will this line of code look in a backend-agnostic manner?
Things like CURRENT_TIMESTAMP, LIMIT, ALTER/CREATE TABLE are specific their backends. Ideally the abstraction layer chosen should help reduce these issues.Code:UPDATE song SET iTimesPlayed=iTimesPlayed+1, lastplayed=CURRENT_TIMESTAMP where idSong=%ld
SQL is the tricky part and the main reason why this replacement will not be easy. All the current SQL statements have to be assessed and modified for "portability". Fortunately the command you mention above is "portable" and will work just fine with the big 3 backends (sqlite3, mysql and postgresql).
CapnBry Wrote:Things like CURRENT_TIMESTAMP, LIMIT, ALTER/CREATE TABLE are specific their backends. Ideally the abstraction layer chosen should help reduce these issues.
Yes there will be SQL commands that are specific to their backends and will differ from the SQL 2003 standards. However, as XBMC has used SQLite3 a lot of the SQL command extensions you seen in mysql and postgresql have been avoided already and should pose little problem ... touch wood.
CapnBry Wrote:At the very least I'd expect the chosen dbiplus replacement to support 1 (if not both) of the issues I listed above.
Whilst I agree OpenDBX is not the holy grail of solutions, I believe it satisfies more of the essential requirements as a replacement than it lacks in desirable requirements.