The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
Difference between revisions of "GOCDB/Release4/Development/v5"
| Line 30: | Line 30: | ||
= Changes = | = Changes = | ||
The move to Doctrine will introduce some important changes | The move to Doctrine will introduce some important changes. These are outlined below. | ||
== Portal URLs == | == Portal URLs == | ||
| Line 37: | Line 37: | ||
https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=123&grid_id=0 | https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=123&grid_id=0 | ||
In Doctrine, each entity receives an ID unique only to that entity type. There is a site with ID 123, a service endpoint with ID 123 and a downtime with ID 123. The new URL will reflect the entity type: | In v5 using Doctrine, each entity receives an ID unique only to that entity type. There is a site with ID 123, a service endpoint with ID 123 and a downtime with ID 123. The new URL will reflect the entity type: | ||
https://goc.egi.eu/portal/index.php?Page_Type=Site&id=123 | https://goc.egi.eu/portal/index.php?Page_Type=Site&id=123 | ||
| Line 50: | Line 50: | ||
== PI XML Output Values == | == PI XML Output Values == | ||
In the GOCDB PI there are a number of PROM specific XML values that will change when we move to Doctrine: PRIMARY_KEY, ID and GOCDB_PORTAL_URL. These are highlighted in RED below: | In the GOCDB v4 PI there are a number of PROM specific XML values that will change when we move to Doctrine: PRIMARY_KEY, ID and GOCDB_PORTAL_URL. These are highlighted in RED below: | ||
[[File:Get_Site_Fields.png]] | [[File:Get_Site_Fields.png]] | ||
* ID fields will NOT be consistent between v4 and v5 (each new object will get a new Doctrine ID value). | |||
* The GOCDB_PORTAL_URL will therefore NOT be consistent between v4 and v5. | |||
* The v4 PRIMARY_KEY value will be carried over only for Sites and Downtimes, see below: | |||
<br/> | <br/> | ||
| Line 60: | Line 62: | ||
<b>Update Aug 2013 - Preserving v4 <PRIMARY_KEY> element values</b> | <b>Update Aug 2013 - Preserving v4 <PRIMARY_KEY> element values</b> | ||
<br/> | <br/> | ||
* v4 <PRIMARY_KEY> element <u>values</u> are carried over for <b>Sites</b> | * v4 <PRIMARY_KEY> element <u>values</u> are carried over for <b>Sites</b> and <b>Downtimes</b> to maintain backward compatiblity (get_site, get_site_list, get_downtime) | ||
* No preservation of v4 <PRIMARY_KEY> element values are planned for: | |||
* No preservation of v4 <PRIMARY_KEY> element values planned for: | ** get_service_endpoint (no reports that v4 SE PRIMARY_KEY values are required for carry over) | ||
** get_service_endpoint (no | |||
** get_ngi | ** get_ngi | ||
** get_service_group | ** get_service_group | ||
| Line 69: | Line 70: | ||
== PI get_downtime method paging == | == PI get_downtime method paging == | ||
* The mandatory | * The ‘get_downtime’ PI method requires a new mandatory ‘&page’ parameter to limit the number of returned downtimes to a sensible limit (500 in each page). | ||
* Required to reduce server load and max query execution time (consider ~10,000 XML downtimes rendered in one page). | |||
* The get_downtime method should be re-issued each time | * The 'get_downtime' method should be re-issued by the client and each time the page parameter should be incremented by one until an empty <results/> element is returned indicating no more results, e.g. | ||
** https://goc.egi.eu/gocdbpi/public/?method=get_downtime&page=1 | |||
** https://goc.egi.eu/gocdbpi/public/?method=get_downtime&page=2 | |||
** https://goc.egi.eu/gocdbpi/public/?method=get_downtime&page=3 | |||
= Request for Comments = | = Request for Comments = | ||
If these changes affect a system that reads from the GOCDB-PI or links to the web portal please [mailto:gocdb-admins@mailman.egi.eu let us know]. | If these changes affect a system that reads from the GOCDB-PI or links to the web portal please [mailto:gocdb-admins@mailman.egi.eu let us know]. | ||
Revision as of 16:51, 5 August 2013
| Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
| GOC DB menu: | Home • | Documentation Index • |
<< Back to GOCDB/Release4/Development
v5 Dropping PROM for Doctrine
By replacing the PROM model with the Doctrine ORM GOCDB will support RDBMSs other than Oracle. This will be released as GOCDB v5 (early Sept). Important changes to the Portal URLs and to the PI are detailed below.
Benefits
- Write code once, deploy to Oracle, MySQL, Postgres, SQLite.
- Much simpler than the GOCDB/PROM model (see query comparison below)]
- Easier for other projects to extend / modify
- Easier for new developers to learn
- Better performance
- Reduced risk of failover performance issues
Drawbacks
- Data will be deleted rather than marked as 'off'. We therefore require an audit table to record who/when performed data deletions/updates (this is on the requirements roadmap ).
- Loose some flexiblity as the DB will manage the relationships (FKs) between entities rather than the application (but in turn we gain performance/simplicity/db-agnostic).
- Changes to some PI methods (paging and carrying over v4 PKs)
- Changes to Portal URLs and object IDs (below)
Changes
The move to Doctrine will introduce some important changes. These are outlined below.
Portal URLs
In PROM, each "entity" (site, service endpoint, downtime) was assigned an ID from a global pool. There is only one object 123, the GRIDOPS-GOCDB site. The following URL is used to access an entity regardless of type:
https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=123&grid_id=0
In v5 using Doctrine, each entity receives an ID unique only to that entity type. There is a site with ID 123, a service endpoint with ID 123 and a downtime with ID 123. The new URL will reflect the entity type:
https://goc.egi.eu/portal/index.php?Page_Type=Site&id=123
https://goc.egi.eu/portal/index.php?Page_Type=Service_Endpoint&id=123
https://goc.egi.eu/portal/index.php?Page_Type=Downtime&id=123
(...and so on for each GOCDB entity type)
PI XML Output Values
In the GOCDB v4 PI there are a number of PROM specific XML values that will change when we move to Doctrine: PRIMARY_KEY, ID and GOCDB_PORTAL_URL. These are highlighted in RED below:
- ID fields will NOT be consistent between v4 and v5 (each new object will get a new Doctrine ID value).
- The GOCDB_PORTAL_URL will therefore NOT be consistent between v4 and v5.
- The v4 PRIMARY_KEY value will be carried over only for Sites and Downtimes, see below:
Update Aug 2013 - Preserving v4 <PRIMARY_KEY> element values
- v4 <PRIMARY_KEY> element values are carried over for Sites and Downtimes to maintain backward compatiblity (get_site, get_site_list, get_downtime)
- No preservation of v4 <PRIMARY_KEY> element values are planned for:
- get_service_endpoint (no reports that v4 SE PRIMARY_KEY values are required for carry over)
- get_ngi
- get_service_group
- Please check!
PI get_downtime method paging
- The ‘get_downtime’ PI method requires a new mandatory ‘&page’ parameter to limit the number of returned downtimes to a sensible limit (500 in each page).
- Required to reduce server load and max query execution time (consider ~10,000 XML downtimes rendered in one page).
- The 'get_downtime' method should be re-issued by the client and each time the page parameter should be incremented by one until an empty <results/> element is returned indicating no more results, e.g.
Request for Comments
If these changes affect a system that reads from the GOCDB-PI or links to the web portal please let us know.