[PD-dev] Fwd: Fwd: Fwd: Connecting up an SQL Database to PD

[Mike McGonagle]

On 11/12/07, Frank Barknecht <fbar at footils.org> wrote:
> Hallo,
> Mike McGonagle hat gesagt: // Mike McGonagle wrote:
>
> > I was just thinking, should the result sets be returned as TAGGED
> > data? Meaning, should the name of the column precede the data in the
> > returned PD list? While I can see that this would be useful, it would
> > also require more processing to merge the keys with the data. I have
> > so far been assuming that it is only the data that gets returned.
>
> If it's a determinisic object, I'd say you can omit the tags. If a
> user wants tags, she can use "select id from table" or so to get her
> own id-tags in the results. it would be useful to have a second outlet
> [textfile]-style to signal the end of results.

Maybe there could be an option to have the keys returned, or not. I
would figure that with most databases used with PD would already know
the format of the database, and therefore would not really require the
handling of the keys.

As far as the second outlet, yes, I was going in that direction. It
would serve two purposes, one to indicate the end of the result set
has been reached (outputting a 'bang'), and the second would be a list
containing an error message from the database for any queries that
error out.

> Generally I prefer working with databases using ORMs like
> sqlobject.org instead of with SQL queries directly, but I don't know
> how a good and simple way to design something like an SQL-ORM for Pd
> could look like.
>
> Another thing that may be important in the long run would be a common
> interface for all DB adapters. So the Pd object for sqlite shouldn't
> behave too differenty from the objects for postgresql, mysql, etc.
> Again that's something I like about Pythons SQLObject (or other ORMs
> like SQLAlchemy ...): They provide an abstract interface to lots of
> backends. Probably something like this exists for C/C++ as well, you
> may want to g**gle for it. (Oh, and maybe prototyping and testing such
> a general purpose SQL class for Pd is easier in Lua or Python, but I
> think I already mentioned that. ;)

Well, this is one of the goals. Provide for UNIVERSAL access. At the
same time, would a trade off be in performance? One of the things that
I would think using something like sqlite as a simple file database,
is that there is no intervening layers to go through. You are "closer"
to the data, as it is on your machine, stored in a file. No drivers or
networking involved.

But, first things first. I do think that it is important to have a
single interface for these things, and one way to use them. Then once
you get those things down, you can tweak things by replacing the
classes with those of your choice.

Mike

>
> Ciao
> --
>  Frank Barknecht                                     _ ______footils.org__
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>


-- 
Help the Environment, Plant a Bush back in Texas!

"I place economy among the first and most important republican
virtues, and public debt as the greatest of the dangers to be feared.
To preserve our independence, we must not let our rulers load us with
perpetual debt."
-- Thomas Jefferson, third US president, architect and author (1743-1826)

"Give Peace a Chance" -- John Lennon (9 October 1940 – 8 December 1980)

Peace may sound simple—one beautiful word— but it requires everything
we have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician

If you think you can, or you think you can't, you are probably right.
—Mark Twain

"Art may imitate life, but life imitates TV."
Ani DiFranco