Thread: Working oin pgAdmin2

Working oin pgAdmin2

From
Jean-Michel POURE
Date:
Dear Dave,

I got rid of manual SQL constructions in pgSchema->Views, just for testing
and demonstration. Don't kill me, the job is more or less clean.

This demonstrates we could easily "mask" all SQL in pgSchema->Tables,
Triggers, etc... And it could be possible to do the same in pgAdmin2. This
makes it easy for developpers as they do not have to care for SQL. And this
is the beauty of the code to mask SQL.

Ultimately, this will allow an ***easy*** implementation of abstraction
layers to query MySQL, Oracle and MS SQL Server from pgAdmin2.

Last week-end, I had a deep look at libgda. This is a quite simpleabstraction
layer written in plain C. It does have the power or a C++ object oriented
abstractionlayer. But it has nice things like abstract types and type
conversion (I guess).

We could well implement "database providers" in pgSchema to offer basic
access to other database schemas. This could well be in read-only in a first
time. This is not for now are there are more important projects (ALTER TABLE,
Cygwin installer) going on.

But if we move SQL queries ***out*** of pgAdmin2 and pgSchema->Tables,
Triggers, etc.., this will be possible in a middle-term future. We need more
abstraction from SQL...

What do you think?

Cheers,
Jean-Michel

Re: Working oin pgAdmin2

From
Dave Page
Date:

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 24 February 2002 08:47
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Working oin pgAdmin2
>
>
> Dear Dave,
>
> I got rid of manual SQL constructions in pgSchema->Views,
> just for testing
> and demonstration. Don't kill me, the job is more or less clean.

Hmmm.

> This demonstrates we could easily "mask" all SQL in pgSchema->Tables,
> Triggers, etc... And it could be possible to do the same in
> pgAdmin2. This
> makes it easy for developpers as they do not have to care for
> SQL. And this
> is the beauty of the code to mask SQL.

If a developer working on pgSchema cannot code the required SQL, then this
is *not* the project for him to be hacking. That's like a cowboy who can't
use a lassoo...

> Ultimately, this will allow an ***easy*** implementation of
> abstraction
> layers to query MySQL, Oracle and MS SQL Server from pgAdmin2.

I am not interested in implementing this., at least nothing more than can be
achieved via the ODBC API alone.

> This is not for now are there are more important
> projects (ALTER TABLE,
> Cygwin installer) going on.

Yes.

Regards, Dave.

Re: Working oin pgAdmin2

From
Jean-Michel POURE
Date:
Le Dimanche 24 Février 2002 21:19, Dave Page a écrit :
> If a developer working on pgSchema cannot code the required SQL, then this
> is *not* the project for him to be hacking. That's like a cowboy who can't
> use a lassoo...

Let's say a French man without a baguette. Oh, now I see...

IMHO, this is not the question of knowing how to write SQL or not. It would
just be great to query legacy databases using pgAdmin2. This will help me
learn new things and improve my skills.

I only have the impression that if we move SQL out of Views.cls to pgViews,
and so on, we could consider pgViews to be a PostgreSQL provider. Let's call
this wheatever we like : SQL provider, SQL parser, SQL abstract layer. I
prefer "provider" as this is the term used by libgda.

Then, we only have to code providers to add new database access to pgAdmin.
Provider should also tell pgAdmin2 which features are available and which are
not.

So after ALTER TABLE and Cygwin installer, I will have a try, on a separate
folder. libgda is not well structured (plain C). I may not help this project
and will focus on pgSchema.

In between :
1) I still don't know how to refresh treeview when triggers change tables.

2) PostgreSQL 7.2 internals are really UTF-8, provided that the database is
Unicode. This is great for programming server-side. Unfortunately,
highlightBox is not really UTF-8 compatible.

Now, my problem is that Functions need to be written in UTF-8. Yes, my
friend, you read it. I can't even write an "é" or anything like "français" in
PLpgSQL code. During all the afternoon I fixed such errors in my code.

So what should we do? Buy some good utf-8 controls? Migrate to KDE3? Invest
in $M new VB for cowboys? Buy a new 2000 euros lassoo?

Maybe we should ask some more information to Hiroshi about UCS-2. I write a
mail and post it on ODBC right now.

Cheers,
Jean-Michel

Re: Working oin pgAdmin2

From
Dave Page
Date:

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 24 February 2002 21:23
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Working oin pgAdmin2
>
>
> Le Dimanche 24 Février 2002 21:19, Dave Page a écrit :
> > If a developer working on pgSchema cannot code the required
> SQL, then
> > this is *not* the project for him to be hacking. That's
> like a cowboy
> > who can't use a lassoo...
>
> Let's say a French man without a baguette. Oh, now I see...

I prefer crepes (au chocolat - is that right? It's about 14 years since I
did French at school), but that's just me :-)

> IMHO, this is not the question of knowing how to write SQL or
> not. It would
> just be great to query legacy databases using pgAdmin2. This
> will help me
> learn new things and improve my skills.

Learning more is great, but pgSchema is so totally PostgreSQL specific, that
I think we'd be far better adding new classes to handle ODBC connections to
*any* database. The level of integration would be far less, but you could
still browse tables, data, indexes and views. And it would work with any
ODBC datasource.

What I will not do, is sacrifice PostgreSQL functionality just to allow
access to other dbms's.

> I only have the impression that if we move SQL out of
> Views.cls to pgViews,
> and so on, we could consider pgViews to be a PostgreSQL
> provider. Let's call
> this wheatever we like : SQL provider, SQL parser, SQL
> abstract layer. I
> prefer "provider" as this is the term used by libgda.

The two types of class go hand in hand and will not work without each other.
In an object library such as pgSchema, the classes work in pairs - one
(pgView) provides the basic type, and one (Views) has the responsibility of
maintaining the collection of objects of that type.

An example is the Field/Fields classes in a Recordset.

In pgSchema, these pairs of classes *are* the abstration layer, and they are
very PostgreSQL specific. For example, how many dbms's have oids? How many
have sequences with the same properties as PostgreSQL?

Another problem, is that other dbms's may not share the same object
hierarchy as PostgreSQL. For example, Oracle has Schemas which add a new
level into the hierarchy. When PostgreSQL adds support for Schemas in 7.3,
we will add 2 classes for them, and move some existing classes (tables,
functions, views etc.) into there, and leave others (operators, types etc)
where they are. That hierarchy will then not be compatible with Informix SE
for example.

I think the most effective way to go would be to write new classes
pgSchema.ODBCServer, pgSchema.ODBCTables, pgSchema.ODBCTable, and have an
ODBCServers collection at the top of the hierarchy, next to pgServer. This
can then provide a hierarchy that is compatible with the sort of data we'd
expect from an ODBC driver. In the future we could add an OLEDBServers
collection in a similar vein.

>
> In between :
> 1) I still don't know how to refresh treeview when triggers
> change tables.

Search for the current trigger node as we do when we search for a table node
when renaming and delete it. Then search for the new table node, and add the
trigger node to the Triggers sub node. I have never done this so I have no
code for you to copy, only the existing code to locate nodes.

> 2) PostgreSQL 7.2 internals are really UTF-8, provided that
> the database is
> Unicode. This is great for programming server-side. Unfortunately,
> highlightBox is not really UTF-8 compatible.
>
> Now, my problem is that Functions need to be written in
> UTF-8. Yes, my
> friend, you read it. I can't even write an "é" or anything
> like "français" in
> PLpgSQL code. During all the afternoon I fixed such errors in my code.
>
> So what should we do? Buy some good utf-8 controls?

Certainly not. That opens a whole new can of licencing problems. Can we
write anything ourselves? Currently we'd need to fix the ListView, Textbox &
RTFTextbox...

> Migrate to KDE3?

Have you tried compiling it from source? Takes forever... Besides, how's
your C/C++?

> Invest
> in $M new VB for cowboys?

Well as soon as my supplier get their fingers out, I'll have 4 copies of
visual studio.NET for us here, but with all I've read about vb.NET, I'm very
dubious about porting pgAdmin II to it.

I've read in a number of places that it's so subtley different to VB6, that
many experienced developers might find it easier to learn C# from scratch.

And we should have a C# compiler and classes for Linux within the next few
months....

> Buy a new 2000 euros lassoo?

Euros? Don't mention them to an Englishman - you're liable to get abuse back
;-)

/Dave.

Re: Working oin pgAdmin2

From
Jean-Michel POURE
Date:
> I prefer crepes (au chocolat - is that right? It's about 14 years since I
> did French at school), but that's just me :-)
Don't hesitate to practice and visit me with your wife.

> I think the most effective way to go would be to write new classes
> pgSchema.ODBCServer, pgSchema.ODBCTables, pgSchema.ODBCTable, and have an
> ODBCServers collection at the top of the hierarchy, next to pgServer. This
> can then provide a hierarchy that is compatible with the sort of data we'd
> expect from an ODBC driver. In the future we could add an OLEDBServers
> collection in a similar vein.
Does ODBC provide function list, views, triggers.

> > Migrate to KDE3?
> Have you tried compiling it from source? Takes forever... Besides, how's
> your C/C++?
Poor as you can imagine, but I can learn.

Re: Working oin pgAdmin2

From
Dave Page
Date:

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 24 February 2002 23:07
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: Working oin pgAdmin2
>
>
> > I think the most effective way to go would be to write new classes
> > pgSchema.ODBCServer, pgSchema.ODBCTables,
> pgSchema.ODBCTable, and have
> > an ODBCServers collection at the top of the hierarchy, next to
> > pgServer. This can then provide a hierarchy that is compatible with
> > the sort of data we'd expect from an ODBC driver. In the future we
> > could add an OLEDBServers collection in a similar vein.
> Does ODBC provide function list, views, triggers.

No, (well, views, yes). But that's the problem, functions are very dbms
specific. The only way we could incorporate support for these things is by
building an orSchema, an msSchema, an ixSchema... This is a major job that I
do not wish to undertake, though I would consider an ODBC or OLEDB layer. I
think the work involved in getting pgAdmin to work with PostgreSQL 7.3 is
going to be a mammoth task on it's own. the addition of Schemas will cause a
major change in the object hierarchy the effects of which will be felt in
just about every function or subroutine there is.

Regards, Dave.