[livesupport-dev] why postgres? - Airtime Development Discussions on Sourcefabric Forum

import

just out of curiosity, are there specific reasons why livesupport uses postgres (as opposed to, for instance, mysql)? I've done a lot with mysql, and want to get an existing application as well as a few windows things to work with livesupport, which would be a whole lot easier for me if mysql was available. I was just wondering what the rationale was...

------------------------------------------
Posted to Phorum via PhorumMail

import

kaurtech@gmail.com wrote:
> which would be a whole lot easier for me if mysql was available. I was just wondering what the rationale was...

Maybe i'm going to sound stupid Wink

But wasn't unixodbc used for this
program? Which means you can use any database supported by unixodbc.

Stefan

------------------------------------------
Posted to Phorum via PhorumMail

import

If this is the case, why does the documentation/manual give this advisory:

"LiveSupport expects a PostgreSQL database, version 7.4 or later, to
be installed on your system. The database will be accessed through
TCP/IP, usually via the localhost interface. To achieve this, make
sure to make the following changes to the PostgreSQL configuration
files."

Curiously, both unixODBC and postgreSQL are requirements, it
seems...which to me implies that unixODBC might be used as an
abstraction layer for database access for some things, but that some
parts of livesupport (still?) depend on postgresql (because those
portions access pgsql directly?). Or perhaps postgres is just
included as an example of a database to be used ...?

Jackson

On 6/1/05, Stefan de Konink wrote:
> kaurtech@gmail.com wrote:
> > which would be a whole lot easier for me if mysql was available. I was just wondering what the rationale was...
>
> Maybe i'm going to sound stupid Wink

But wasn't unixodbc used for this
> program? Which means you can use any database supported by unixodbc.
>
>
> Stefan
>

------------------------------------------
Posted to Phorum via PhorumMail

import

At 23:59 01.06.2005, you wrote:
>Or perhaps postgres is just
>included as an example of a database to be used ...?

i remember in the early days of the development, postgrsql was chosen for
some specific features - but as i am not a developer, i can't remember. i
think some rollback or clustering of queries, caching of queries??? please,
someone from the team, help me out Wink

on the other hand - for the same reason of not being a developer - i don't
know if any of the postgresql features were ever utilised or if it should
work with mysql - yet untested. there is definately an abstraction layer.
bu that does not necessarily mean that all db should work.
Micz Flor
____________________________________
[Konzept und Entwicklung]
Redaktion und Alltag - Flor Lay GbR
____________________________________
Pasteurstrasse 8
10407 Berlin
t: +49.30.44044999
f: +49.30.42085272
e: flor@redaktionundalltag.de
____________________________________
http://www.fluter.de
http://www.redaktionundalltag.de

------------------------------------------
Posted to Phorum via PhorumMail

import

Stefan de Konink wrote:
> Maybe i'm going to sound stupid Wink

But wasn't unixodbc used for this
> program? Which means you can use any database supported by unixodbc.

yes and know.

the parts written in C++ (the scheduler, mainly) usis unixODBC to
connect to the database.

I don't know what connectivity library the PHP parts use to connect to
the database.

but all our SQL scripts are now written with PostgreSQL in mind. for the
C++ part, this is all separated, with the ability to add multiple
implementations, and chose among them at run-time, via the configuration
file. (I don't know about the PHP part).

so the answer for mysql support: it's more to it than just pointing the
data source to a mysql instance, but it can be done, if all related SQL
statements are ported to mysql. (any anyone is free to do so Smile

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

Akos Maroy wrote:
> so the answer for mysql support: it's more to it than just pointing the
> data source to a mysql instance, but it can be done, if all related SQL
> statements are ported to mysql. (any anyone is free to do so Smile

I'm happy with PostgreSQL, but wouldn't it be better to get all SQL
statements in a configuration file, so we could eventually connect to
any ODBC host and query by the specific database?

Stefan

------------------------------------------
Posted to Phorum via PhorumMail

import

Stefan de Konink wrote:
> I'm happy with PostgreSQL, but wouldn't it be better to get all SQL
> statements in a configuration file, so we could eventually connect to
> any ODBC host and query by the specific database?

it's more than just the statements, you have to write different ODBC
code if you use different statements.

but, as I wrote before, all stuff specific to a certain database server
is separated by now already. just look at the PostgresqlPlaylog and
PostgresqlScheduler classes in products/scheduler/src ... Anyone can
just create mysql-specific implementations of the same, and that's all
you need to support mysql as far as the scheduler is concerned..

(in the PHP source, I don't know how separated these things are..)

------------------------------------------
Posted to Phorum via PhorumMail

import

On Thu, 02 Jun 2005 09:44:39 +0200 Akos Maroy wrote:
> Stefan de Konink wrote:
> > I'm happy with PostgreSQL, but wouldn't it be better to get all SQL
> > statements in a configuration file, so we could eventually connect to
> > any ODBC host and query by the specific database?
>
> it's more than just the statements, you have to write different ODBC
> code if you use different statements.
>
> but, as I wrote before, all stuff specific to a certain database server
> is separated by now already. just look at the PostgresqlPlaylog and
> PostgresqlScheduler classes in products/scheduler/src ... Anyone can
> just create mysql-specific implementations of the same, and that's all
> you need to support mysql as far as the scheduler is concerned..
>
> (in the PHP source, I don't know how separated these things are..)

It's similar in PHP part - I've used PEAR::DB class.
Porting to MySQL is not immediate thing, but possible.

But I don't know how far is transaction support in MySQL, because
transactions are very useful for data consistency in storageServer.

Tomas Hlava
th@red2head.com

------------------------------------------
Posted to Phorum via PhorumMail

Howdy, Stranger!

Categories

Poll

Top Posters