Обсуждение: Packages, Repository and Rebuilding
Hello Dave and all, I know we discussed about it already, so drop this mail for the moment if you don't have time. I would like to work on packages, repository and rebuilding features in pgAdmin 2. Simply because I have to manage several databases and it becomes more and more difficult to move code from one database to another. PostgreSQL core team wron't implement these features before a long time, I need them now. Do you have any spec ? Are you working on these features ? We need to define the Schema tables of the repository server (pgadmin_dev_* -> pgschema_blabla). I wron't be able to start before one or two weeks, then I plan to concentrate on these features. As usual, I don't want to start something before we agree on everything. I will not upload code to CVS at the beginning to avoid breaking things. What's on your agenda my friend? Cheers, Jean-Michel POURE
> -----Original Message----- > From: Jean-Michel POURE [mailto:jmpoure@axitrad.com] > Sent: 20 September 2001 14:20 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] Packages, Repository and Rebuilding > > > Hello Dave and all, > > I know we discussed about it already, so drop this mail for > the moment if > you don't have time. > > I would like to work on packages, repository and rebuilding > features in > pgAdmin 2. > Simply because I have to manage several databases and it > becomes more and more difficult to move code from one > database to another. > > PostgreSQL core team wron't implement these features before a > long time, I > need them now. > Do you have any spec ? Are you working on these features ? Version control should be built in from the ground up imo. Lifted from another email I wrote: Some thoughts I had; - vc should be enabled per database - all appropriate pgXxx classes in pgSchema should have a Versions collection. This will be a collection of basically the same class, but without add/drop/edit methods, writable properties or another Versions collection. - vc should be implemented in pgSchema, which should autodetect if it's enabled. Rollback methods must be included. - data storage should be in the db, in the *minimum* no. of tables possible which pgSchema must maintain/upgrade/self repair. All object versions should include uid, timestamp & version no. as well as *all* properties of the object. > We need to define the Schema tables of the repository server > (pgadmin_dev_* > -> pgschema_blabla). Yes, as I said above, this should be kept to the absolute bare minimum of tables. I don't want the vast array of SSOs we had with that last version (many people didn't like them). One thing that did cross my mind the other day - all that messing about figuring out dependencies that we (mainly you) worked on was somewhat unnecessary - just do everything in oid order and everything should be OK! > I wron't be able to start before one or two weeks, then I plan to > concentrate on these features. OK. > As usual, I don't want to start something before we agree on > everything. I will not upload code to CVS at the beginning to > avoid breaking things. OK. I think this should be done on a branch (once we figure out how to do that!). That way, I can continue with the base release. > What's on your agenda my friend? - Migration Wizard (currently banging my head against a brick wall). - Reverse Engineering Wizard (write full SQL scripts/publish databases to other datasources). To be honest though, both Mark & I are have done so much programming recently that neither of us have much enthusiasm right now and just can't get started on anything. Quite frankly I just want to go down the pub and get pi**ed. Give it a couple of weeks and that should pass though :-) /Dave.
>Functions don't have indexes. Sorry, it is the converse, I meant create an index on function (column). Let's take the example of a view: it can incorporate multiple functions, in case the view OID itself does not suffice. Do I miss something? >No, basically it will dump the schema as an sql script from the selected >server or database. Alternatively, it will publish (==copy) the schema to >another specified database(s). Basically a mechanism for moving your schema >from a dev or staging server to one or more production servers. This is what I need, good. Cheers/JMP
> -----Original Message----- > From: Jean-Michel POURE [mailto:jmpoure@axitrad.com] > Sent: 20 September 2001 15:39 > To: Dave Page > Subject: RE: [pgadmin-hackers] Packages, Repository and Rebuilding > > > > >- Migration Wizard (currently banging my head against a brick wall). > We need to be able to define local settings: numerical (comma > or point > delimiter) and date (dd/mm/yyyy or mm/dd/yyyy). > Otherwise, importing does not work on French Windows systems. Yes, the OO mode I'm designing should cope with these issues easily. > >- Reverse Engineering Wizard (write full SQL scripts/publish > databases > >to other datasources). > What is it exactly? Is it you want to parse batch SQL scripts > from MySQL, > Oracle and MsSQL? No, basically it will dump the schema as an sql script from the selected server or database. Alternatively, it will publish (==copy) the schema to another specified database(s). Basically a mechanism for moving your schema from a dev or staging server to one or more production servers. > Why not extend pgSchema with the next version of VB > (inheritance)? Database abstraction layers are usually built > using inheritance. Partly because I'm not convinced that the next version of VB is the way to go yet. I've heard that it doesn't work on Win95 for example. > >One thing that did cross my mind the other day - all that > messing about > >figuring out dependencies that we (mainly you) worked on was > somewhat > >unnecessary - just do everything in oid order and everything > should be > >OK! > Interesting if it works. What about cross-dependencies (view > has functions, > functions have indexes, indexes might be dropped and > recreated) ? Functions don't have indexes. Anyway, as far as I can tell, this is how pg_dump works. Until it is possible to really alter a view or function, the oid will always denote the order in which objects were created, hence you don't need a pg_dependancies table yet. Once you can edit objects, then such a table *will* be required for pg_dump to work sensibly. > Are oids primary keys at database level? > PostgreSQL members have been > discussing a lot about this rebuilding feature. > I remember reading "We will not implement this feature before a real > dependency table is built" on PostgreSQL hackers. Is this so simple? Yes, oids are guaranteed unique (and sequential) so you can treat them as a primary key quite safely. > Have a nice beer. Cheers /Dave. > > >
> -----Original Message----- > From: Jean-Michel POURE [mailto:jmpoure@axitrad.com] > Sent: 20 September 2001 16:00 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Packages, Repository and Rebuilding > > > > >Functions don't have indexes. > Sorry, it is the converse, I meant create an index on > function (column). Let's take the example of a view: it can > incorporate multiple functions, in > case the view OID itself does not suffice. > Do I miss something? Simple, create all indexes last of all. The optimizer will figure out what indexes to use (and cache the results) on a per query basis at runtime (if I understand it correctly), hence you can add an index at any time and it will be used where appropriate. The functions don't care about indexes at creation time. Like I, this is how I understand PostgreSQL does it. I may well be wrong. > >No, basically it will dump the schema as an sql script from the > >selected server or database. Alternatively, it will publish (==copy) > >the schema to another specified database(s). Basically a > mechanism for > >moving your schema from a dev or staging server to one or more > >production servers. > This is what I need, good. Thought you'd like it! Dave.