Jump to navigation Jump to search
<!-- Posted on the mailing list by Paul Dreik <email@example.com> --> <pre> On 22 December 2011 20:53, Paul Dreik <firstname.lastname@example.org> wrote: > 2011-12-21 13:02, dirk skrev: >> On Wed, 2011-12-21 at 09:34 +0100, Paul Dreik wrote: >>> 2011-12-20 23:37, email@example.com skrev: >>>> Hi all - >>>> Couldn't make the database package work, and after a reasonable amount >>>> of googling I concluded I was not the only one. >>>> As a solution I made my own .oct file that queries SQLite & returns a >>>> cell array of the results; kudos to SQLite's "amalgamation" file and >>>> Octave's "mkoctfile." >>>> >>>> - is this the right forum to ask the next 2 questions? >>>> - is anyone interested in connecting SQLite to octave? >>>> - what's my next reasonable step (if any): make a package, post code >>>> somewhere (here?), or... ? >>>> >>>> thanks, >>>> dirk mayhew >>>> ps and thank you also to Xavier Delacour - I would use your code if I could >>>> >>> Hi, no you are certainly not the only one! >>> I have also made an sqlite octave package, but only for private use. I >>> think it is wise to discuss on how to implement the interface to such a >>> toolbox. >>> * should one mimic the c interface? >>> * should one mimic the perl dbi interface? >>> * mimic the matlab database interface? >>> * make a new one? >>> What is your opinion? >>> >>> This is the right place to discuss and send code suggestions. >>> >>> Paul Dreik >>> >> Thanks, Paul - those are good questions. >> >> I assume by "c interface" you mean ODBC? I believe that would be best, >> but requires more work... I suspect this is the direction Xavier took >> with his database package. >> >> Given a choice between perl, Matlab and "create your own," the community >> would probably prefer a solution that "looks like Matlab." That is, >> without a GUI and no Matlab-specific I/O, I assume. >> >> What do you think? >> > No, I mean the sqlite c interface described in > http:// sqlite. org/ c3ref/ intro.html > > Using odbc seems to be yet another method to connect. It seems like > there is an odbc driver for sqlite. > http://www.sqlite.org/cvstrac/wiki?p=SqliteOdbc > I know the matlab database toolbox can connect through odbc, that is how > I used it a few years ago. > > > I assembled the list below with my comments and links to documentation. > > I think the matlab database toolbox is a bit messy. It is also quite > big, so users expecting to use octave database as a dropin replacement > will probably never be satisfied unless they only use a very basic > subset. It handles multiple databases, which is good. > The documentation is at > http://www.mathworks.se/help/toolbox/database/ug/f4- 6010.html > > I like the relatively clean interface of the sqlite c interface. This is > how I built my toolbox. (It was a while ago, so I do not remember how > closely I followed the c interface). Obviously this only supports > sqlite, so It may be a poor choise for octave database toolbox unless it > is an octave sqlite toolbox. > Documentation for api introduction is at http://sqlite .org/cintro.html > > I also like the perl dbi interface. It handles multiple databases, so it > may be a good example on how to make an octave interface. > An easy to read introduction exists at > http://www.perl.com/pub/1999/10/DBI.html > > I have never worked directly to odbc. Looking at the introductory > material on > http://msdn.microsoft.com/en-us/library/windows/desktop/ms714078%28v=vs.85%29.aspx > I say lets stick to any other method... > The good thing is that it handles multiple databases and it is cross > platform. > > The existing octave database package seems to offer both a generic > interface and wrap the database specific apis. I do not know how well it > performs. Installation failed for me two years ago or so, and it still > fails now (octave 3.4.2 from macports. See attached errors). I assume I > do not have all dependencies installed, but the errors seem to point to > other problems. Have not looked deeper into it. > I do not know if there are any plans for it or what the current status > is. Last update on http://octave- swig.sourceforge.net/octave-db.html > (linked to from http://octave.sourceforge.net/database/overview.html) > was 2008, but the package was released 2009. > The swig operations seem like black magic to me. > > I do not currently have the time or need to work on this now, but I am > willing to share my octave package (sqlite c interface wrapped, more or > less). On 23 December 2011 13:42, dirk <firstname.lastname@example.org> wrote: > On Wed, 2011-12-21 at 19:56 +0000, Carnë Draug wrote: >> Are you able to indetify what's broken in the current package? > > I am not calling it broken, but "difficult to install" or "not > self-contained" would be fair descriptions. On 29 December 2011 16:21, dirk <email@example.com> wrote: > Unfortunately the file size limit prevented me uploading the required > sqlite3. c source file ; it is available via > http://www.sqlite.org/sqlite-amalgamation-3070900.zip > > The resulting .oct acts like a dedicated database server. > Functionally it mimics the existing database "sql" function, but > *without* the pre-requirements of SWIG & an additional external database > server oprogram. > > Can anyone can point me to a "beginner's guide to package creation?" > mkoctfile worked fine for me on Ubuntu and Win7, but I'd guess a tar.gz > supporting pkg install would be better/cleaner/more useful. </pre>
don't know who profits from the mailinglist extract?
== SQLite ==
== redis ==