Обсуждение: 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. 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
> -----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.
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
> -----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.
> 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.
> -----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.