public inbox for [email protected]help / color / mirror / Atom feed
Driver Module 7+ messages / 3 participants [nested] [flat]
* Driver Module @ 2017-01-06 19:07 George Gelashvili <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: George Gelashvili @ 2017-01-06 19:07 UTC (permalink / raw) To: pgadmin-hackers; [email protected] Hi there, We are working on connecting Greenplum to pgAdmin4. Currently we are exploring how modules work in pgAdmin. In an earlier off-thread email it was suggested we look at "the EDB PPAS" as an example of a driver class. We are not entirely clear on what that means. We found: - the BaseDriver in web/pgadmin/utils/driver, documented: https://www.pgadmin.org/docs4/1.x/code_snippets.html?highlight=driver#basedriver - things that look EDB-related in web/pgadmin/utils/driver/psycopg2/__init__.py Is it a good idea to keep looking for EDB PPAS as an example of a driver? Does anyone know exactly where it lives? Thanks! George & Rob ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-08 09:57 Dave Page <[email protected]> parent: George Gelashvili <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Dave Page @ 2017-01-08 09:57 UTC (permalink / raw) To: George Gelashvili <[email protected]>; +Cc: pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> Hi On Friday, January 6, 2017, George Gelashvili <[email protected]> wrote: > Hi there, > > We are working on connecting Greenplum to pgAdmin4. Currently we are > exploring how modules work in pgAdmin. In an earlier off-thread email it > was suggested we look at "the EDB PPAS" as an example of a driver class. We > are not entirely clear on what that means. > > We found: > - the BaseDriver in web/pgadmin/utils/driver, documented: > https://www.pgadmin.org/docs4/1.x/code_snippets.html? > highlight=driver#basedriver > - things that look EDB-related in web/pgadmin/utils/driver/ > psycopg2/__init__.py > > Is it a good idea to keep looking for EDB PPAS as an example of a driver? > Does anyone know exactly where it lives? > I believe 99% of it is simply inherited from the base driver, and (some of?) the rest of it is in web/pgadmin/browser/server_groups/servers/ppas.py. Ashesh, can you help here? You know that code infinitely better than I do. Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-11 16:54 George Gelashvili <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: George Gelashvili @ 2017-01-11 16:54 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> Hi Dave, Thanks for the pointer. We realized that many of the changes we would need to make for supporting Greenplum would need to go where there is pg version checking throughout the code. This is because unlike PPAS which mostly adds additional features, Greenplum is based on postgres 8.3. It looks like much of the version checking logic is repeated at points where the features are differentiated by postgres version. It might make sense at this point to refactor the way that feature flagging is done to be a little bit more unified between server types and postgres versions so that we could for example have logic along the lines of: feature_enablement = FeatureEnablement(postgres_flavor, postgres_version) #... if(feature_enablement.check_internal_triggers ): # feature call here and then in a feature enablement class, reference the various versions and flavors of postgres. Any thoughts on this? Thanks, Tira and George On Sun, Jan 8, 2017 at 4:57 AM, Dave Page <[email protected]> wrote: > Hi > > On Friday, January 6, 2017, George Gelashvili <[email protected]> > wrote: > >> Hi there, >> >> We are working on connecting Greenplum to pgAdmin4. Currently we are >> exploring how modules work in pgAdmin. In an earlier off-thread email it >> was suggested we look at "the EDB PPAS" as an example of a driver class. We >> are not entirely clear on what that means. >> >> We found: >> - the BaseDriver in web/pgadmin/utils/driver, documented: >> https://www.pgadmin.org/docs4/1.x/code_snippets.html?highlig >> ht=driver#basedriver >> - things that look EDB-related in web/pgadmin/utils/driver/psyco >> pg2/__init__.py >> >> Is it a good idea to keep looking for EDB PPAS as an example of a driver? >> Does anyone know exactly where it lives? >> > > I believe 99% of it is simply inherited from the base driver, and (some > of?) the rest of it is in web/pgadmin/browser/server_ > groups/servers/ppas.py. > > Ashesh, can you help here? You know that code infinitely better than I do. > > Thanks. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-12 04:07 Dave Page <[email protected]> parent: George Gelashvili <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Dave Page @ 2017-01-12 04:07 UTC (permalink / raw) To: George Gelashvili <[email protected]>; +Cc: pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> Hi On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili <[email protected]> wrote: > Hi Dave, > > Thanks for the pointer. > We realized that many of the changes we would need to make for supporting > Greenplum would need to go where there is pg version checking throughout the > code. This is because unlike PPAS which mostly adds additional features, > Greenplum is based on postgres 8.3. Isn't Heikki fixing that for your next release? > It looks like much of the version checking logic is repeated at points where > the features are differentiated by postgres version. > > It might make sense at this point to refactor the way that feature flagging > is done to be a little bit more unified between server types and postgres > versions so that we could for example have logic along the lines of: > > feature_enablement = FeatureEnablement(postgres_flavor, postgres_version) > > #... > > if(feature_enablement.check_internal_triggers ): > # feature call here > > and then in a feature enablement class, reference the various versions and > flavors of postgres. > > Any thoughts on this? I worry that the list of features would end up being huge - we're not just talking about basic things like whether DDL triggers are supported, but the catalog schema (e.g. procpid vs. pid in pg_stat_activity) and small things like whether a particular GUC can be set on a tablespace. Ultimately, you have to do a version check at some point though (unless you're proposing to do something similar to probing the DOM in a browser at runtime). Doesn't GP's version string contain additional info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major, int minor) function in the connection class that basically did: return isEdb && BackendMinimumVersion(x, y); Something like that could check other elements of the GP version number. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-12 04:24 Robert Eckhardt <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Robert Eckhardt @ 2017-01-12 04:24 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: George Gelashvili <[email protected]>; pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> On Wed, Jan 11, 2017 at 8:07 PM, Dave Page <[email protected]> wrote: > Hi > > On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili > <[email protected]> wrote: > > Hi Dave, > > > > Thanks for the pointer. > > We realized that many of the changes we would need to make for supporting > > Greenplum would need to go where there is pg version checking throughout > the > > code. This is because unlike PPAS which mostly adds additional features, > > Greenplum is based on postgres 8.3. > > Isn't Heikki fixing that for your next release? > The current release is 8.2, we aren't trying to make that work with pgAdmin4. Heikki did a yeomans work and the next release will be based on 8.3. Future releases should be more than one Postgres version at a time but there was a lot of cleanup to do before we could start the Postgres merging. > > > It looks like much of the version checking logic is repeated at points > where > > the features are differentiated by postgres version. > > > > It might make sense at this point to refactor the way that feature > flagging > > is done to be a little bit more unified between server types and postgres > > versions so that we could for example have logic along the lines of: > > > > feature_enablement = FeatureEnablement(postgres_flavor, > postgres_version) > > > > #... > > > > if(feature_enablement.check_internal_triggers ): > > # feature call here > > > > and then in a feature enablement class, reference the various versions > and > > flavors of postgres. > > > > Any thoughts on this? > > I worry that the list of features would end up being huge - we're not > just talking about basic things like whether DDL triggers are > supported, but the catalog schema (e.g. procpid vs. pid in > pg_stat_activity) and small things like whether a particular GUC can > be set on a tablespace. > > Ultimately, you have to do a version check at some point though > (unless you're proposing to do something similar to probing the DOM in > a browser at runtime). Doesn't GP's version string contain additional > info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major, > int minor) function in the connection class that basically did: > > return isEdb && BackendMinimumVersion(x, y); > > Something like that could check other elements of the GP version number. > Greenplum is about to start leveraging semantic versioning. The version number for the next release will be 5.0.0. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgadmin-hackers mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers > ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-12 14:48 George Gelashvili <[email protected]> parent: Robert Eckhardt <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: George Gelashvili @ 2017-01-12 14:48 UTC (permalink / raw) To: Robert Eckhardt <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> Hi Dave, We looked through the places where there is existing version checking and there isn't a ton of it. Our current plan for supporting Greenplum in pgAdmin4 was not necessarily to support all the features of pgAdmin4, but to at least get the core functionality working. I'm not too concerned about there being a ton of switches, because I don't think most features will need to be disabled. We will also likely make changes to Greenplum to support certain features like query plans rather than doing all the changes on the pgAdmin4 side. What I would like to see though is version checking that happens in one place and is not tied exclusively to either flavor or version, but to a combination of the two. E.g. Greenplum 5.0 might support a feature that is not supported in 8.3 postgres. Tira & George On Wed, Jan 11, 2017 at 11:24 PM, Robert Eckhardt <[email protected]> wrote: > > > On Wed, Jan 11, 2017 at 8:07 PM, Dave Page <[email protected]> wrote: > >> Hi >> >> On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili >> <[email protected]> wrote: >> > Hi Dave, >> > >> > Thanks for the pointer. >> > We realized that many of the changes we would need to make for >> supporting >> > Greenplum would need to go where there is pg version checking >> throughout the >> > code. This is because unlike PPAS which mostly adds additional features, >> > Greenplum is based on postgres 8.3. >> >> Isn't Heikki fixing that for your next release? >> > > The current release is 8.2, we aren't trying to make that work with > pgAdmin4. Heikki did a yeomans work and the next release will be based on > 8.3. Future releases should be more than one Postgres version at a time but > there was a lot of cleanup to do before we could start the Postgres > merging. > > >> >> > It looks like much of the version checking logic is repeated at points >> where >> > the features are differentiated by postgres version. >> > >> > It might make sense at this point to refactor the way that feature >> flagging >> > is done to be a little bit more unified between server types and >> postgres >> > versions so that we could for example have logic along the lines of: >> > >> > feature_enablement = FeatureEnablement(postgres_flavor, >> postgres_version) >> > >> > #... >> > >> > if(feature_enablement.check_internal_triggers ): >> > # feature call here >> > >> > and then in a feature enablement class, reference the various versions >> and >> > flavors of postgres. >> > >> > Any thoughts on this? >> >> I worry that the list of features would end up being huge - we're not >> just talking about basic things like whether DDL triggers are >> supported, but the catalog schema (e.g. procpid vs. pid in >> pg_stat_activity) and small things like whether a particular GUC can >> be set on a tablespace. >> >> Ultimately, you have to do a version check at some point though >> (unless you're proposing to do something similar to probing the DOM in >> a browser at runtime). Doesn't GP's version string contain additional >> info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major, >> int minor) function in the connection class that basically did: >> >> return isEdb && BackendMinimumVersion(x, y); >> >> Something like that could check other elements of the GP version number. >> > > Greenplum is about to start leveraging semantic versioning. The version > number for the next release will be 5.0.0. > > >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> >> -- >> Sent via pgadmin-hackers mailing list ([email protected]) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgadmin-hackers >> > > ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Driver Module @ 2017-01-13 05:48 Dave Page <[email protected]> parent: George Gelashvili <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Dave Page @ 2017-01-13 05:48 UTC (permalink / raw) To: George Gelashvili <[email protected]>; +Cc: Robert Eckhardt <[email protected]>; pgadmin-hackers; [email protected] <[email protected]>; Ashesh Vashi <[email protected]> Hi On Thu, Jan 12, 2017 at 8:18 PM, George Gelashvili <[email protected]> wrote: > Hi Dave, > > We looked through the places where there is existing version checking and > there isn't a ton of it. That's because we went to great lengths to minimise it in pgAdmin 4. It's mostly confined to template selection for SQL now. > Our current plan for supporting Greenplum in > pgAdmin4 was not necessarily to support all the features of pgAdmin4, but to > at least get the core functionality working. > I'm not too concerned about there being a ton of switches, because I don't > think most features will need to be disabled. We will also likely make > changes to Greenplum to support certain features like query plans rather > than doing all the changes on the pgAdmin4 side. OK. From my perspective though, I have to ensure that what we offer in the community is a good experience. If it's not appropriate or necessary to support a feature in GP, that's fine - but it needs to be disabled to prevent users reporting bugs to us > What I would like to see though is version checking that happens in one > place and is not tied exclusively to either flavor or version, but to a > combination of the two. E.g. Greenplum 5.0 might support a feature that is > not supported in 8.3 postgres. Can you do a rough assessment of how many 'features' we'd be likely to need to have the PG driver advertise? That would give a better idea of the extent of the work involved. In principal I'm not against the idea of having a function in each driver that allows us to check for the presence of a given feature, including by-version as required. What I'm against is that becoming a mess of spaghetti... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2017-01-13 05:48 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2017-01-06 19:07 Driver Module George Gelashvili <[email protected]> 2017-01-08 09:57 ` Dave Page <[email protected]> 2017-01-11 16:54 ` George Gelashvili <[email protected]> 2017-01-12 04:07 ` Dave Page <[email protected]> 2017-01-12 04:24 ` Robert Eckhardt <[email protected]> 2017-01-12 14:48 ` George Gelashvili <[email protected]> 2017-01-13 05:48 ` Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox