Re: Add "Global" affiliation to schema?
Referencing by name sounds like the way to go. I created Jira issue VCL-288 and added id=2, name=Global to vcl.sql. -Andy Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are some places where the web code passes an affiliationid of 0 as an argument to a function to mean all affiliations. It would be easier on the web side to not use 0 to mean Global. I think I'm stating the obvious here, but if we use something other than 0, we will definitely have to make sure it is always referenced by name since any installs that already have an affiliation besides Local will end up with a different id than what would be in the vcl.sql file. Josh On Fri January 8 2010 1:44:01 pm Andy Kurth wrote: I agree affiliation.name would be better to use programatically. We will have to document somewhere that the name "Global" should never be altered because the word will need to be hard-coded. I'm also having second thoughts about using an id of 0 for anything. I think it will cause bugs because it evaluates to false. I propose adding id=2, name=Global to vcl.sql. The Local affiliation is already using id=1. For upgrading to the next release, we will need to remember to have a database upgrade script which adds the Global affiliation to the database. Thanks, Andy Aaron Peeler wrote: Sounds good. This is a good approach to allow for unique settings per affiliation. If there are and queries using the affiliation ID, it should probably be changed to use the name. That way the id is just a database id and the affiliation attributes are queried by the name not the id - but I'm not sure if we are using the id anywhere. Aaron --On January 7, 2010 1:34:20 PM -0500 Andy Kurth wrote: I propose adding an additional schema entry to the affiliation table: id: 0 name: "Global" The "0" index in the affiliation table would remain fixed to represent global or system-wide. This will be particularly useful as more and more configuration parameters are stored in the database. The need to distinguish parameters for a specific affiliation versus system-wide parameters has grown as VCL implementations expand to support several institutions. Configuration tables would reference the affiliation table, allowing system-wide and affiliation-specific settings to be treated identically from a programming standpoint. Queries could be written to attempt to retrieve a configuration value for a particular non-zero affiliation ID and default to the global value if it's not set for the affiliation. One thing to be careful of if implemented... any code using/checking the affiliation ID value must not use a true/false evaluation to determine if it's valid because 0 will be a valid index but evaluate as false. Thoughts? Thanks, Andy Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iD8DBQFLR372V/LQcNdtPQMRAgFqAJ4s6qvM70dIHw1oKNP//wjWB7vPowCfeDud vRsQTTw65DBdASMjt05t2uo= =fUKe -END PGP SIGNATURE- -- Andy Kurth Virtual Computing Lab Office of Information Technology North Carolina State University andy_ku...@ncsu.edu 919.513.4090
Re: Add "Global" affiliation to schema?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are some places where the web code passes an affiliationid of 0 as an argument to a function to mean all affiliations. It would be easier on the web side to not use 0 to mean Global. I think I'm stating the obvious here, but if we use something other than 0, we will definitely have to make sure it is always referenced by name since any installs that already have an affiliation besides Local will end up with a different id than what would be in the vcl.sql file. Josh On Fri January 8 2010 1:44:01 pm Andy Kurth wrote: > I agree affiliation.name would be better to use programatically. We will > have to document somewhere that the name "Global" should never be altered > because the word will need to be hard-coded. > > I'm also having second thoughts about using an id of 0 for anything. I > think it will cause bugs because it evaluates to false. I propose adding > id=2, name=Global to vcl.sql. The Local affiliation is already using id=1. > > For upgrading to the next release, we will need to remember to have a > database upgrade script which adds the Global affiliation to the database. > > Thanks, > Andy > > Aaron Peeler wrote: > > Sounds good. This is a good approach to allow for unique settings per > > affiliation. > > > > If there are and queries using the affiliation ID, it should probably be > > changed to use the name. That way the id is just a database id and the > > affiliation attributes are queried by the name not the id - but I'm not > > sure if we are using the id anywhere. > > > > Aaron > > > > > > --On January 7, 2010 1:34:20 PM -0500 Andy Kurth > > > > wrote: > >> I propose adding an additional schema entry to the affiliation table: > >> id: 0 > >> name: "Global" > >> > >> The "0" index in the affiliation table would remain fixed to represent > >> global or system-wide. > >> > >> This will be particularly useful as more and more configuration > >> parameters are stored in the database. The need to distinguish > >> parameters for a specific affiliation versus system-wide parameters has > >> grown as VCL implementations expand to support several institutions. > >> Configuration tables would reference the affiliation table, allowing > >> system-wide and affiliation-specific settings to be treated identically > >> from a programming standpoint. > >> > >> Queries could be written to attempt to retrieve a configuration value > >> for a particular non-zero affiliation ID and default to the global value > >> if it's not set for the affiliation. > >> > >> One thing to be careful of if implemented... any code using/checking the > >> affiliation ID value must not use a true/false evaluation to determine > >> if it's valid because 0 will be a valid index but evaluate as false. > >> > >> Thoughts? > >> > >> Thanks, > >> Andy > > > > Aaron Peeler > > OIT Advanced Computing > > College of Engineering-NCSU > > 919.513.4571 > > http://vcl.ncsu.edu - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iD8DBQFLR372V/LQcNdtPQMRAgFqAJ4s6qvM70dIHw1oKNP//wjWB7vPowCfeDud vRsQTTw65DBdASMjt05t2uo= =fUKe -END PGP SIGNATURE-
Re: Add "Global" affiliation to schema?
I agree affiliation.name would be better to use programatically. We will have to document somewhere that the name "Global" should never be altered because the word will need to be hard-coded. I'm also having second thoughts about using an id of 0 for anything. I think it will cause bugs because it evaluates to false. I propose adding id=2, name=Global to vcl.sql. The Local affiliation is already using id=1. For upgrading to the next release, we will need to remember to have a database upgrade script which adds the Global affiliation to the database. Thanks, Andy Aaron Peeler wrote: Sounds good. This is a good approach to allow for unique settings per affiliation. If there are and queries using the affiliation ID, it should probably be changed to use the name. That way the id is just a database id and the affiliation attributes are queried by the name not the id - but I'm not sure if we are using the id anywhere. Aaron --On January 7, 2010 1:34:20 PM -0500 Andy Kurth wrote: I propose adding an additional schema entry to the affiliation table: id: 0 name: "Global" The "0" index in the affiliation table would remain fixed to represent global or system-wide. This will be particularly useful as more and more configuration parameters are stored in the database. The need to distinguish parameters for a specific affiliation versus system-wide parameters has grown as VCL implementations expand to support several institutions. Configuration tables would reference the affiliation table, allowing system-wide and affiliation-specific settings to be treated identically from a programming standpoint. Queries could be written to attempt to retrieve a configuration value for a particular non-zero affiliation ID and default to the global value if it's not set for the affiliation. One thing to be careful of if implemented... any code using/checking the affiliation ID value must not use a true/false evaluation to determine if it's valid because 0 will be a valid index but evaluate as false. Thoughts? Thanks, Andy Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu -- Andy Kurth Virtual Computing Lab Office of Information Technology North Carolina State University andy_ku...@ncsu.edu 919.513.4090
Re: Add "Global" affiliation to schema?
Sounds good. This is a good approach to allow for unique settings per affiliation. If there are and queries using the affiliation ID, it should probably be changed to use the name. That way the id is just a database id and the affiliation attributes are queried by the name not the id - but I'm not sure if we are using the id anywhere. Aaron --On January 7, 2010 1:34:20 PM -0500 Andy Kurth wrote: I propose adding an additional schema entry to the affiliation table: id: 0 name: "Global" The "0" index in the affiliation table would remain fixed to represent global or system-wide. This will be particularly useful as more and more configuration parameters are stored in the database. The need to distinguish parameters for a specific affiliation versus system-wide parameters has grown as VCL implementations expand to support several institutions. Configuration tables would reference the affiliation table, allowing system-wide and affiliation-specific settings to be treated identically from a programming standpoint. Queries could be written to attempt to retrieve a configuration value for a particular non-zero affiliation ID and default to the global value if it's not set for the affiliation. One thing to be careful of if implemented... any code using/checking the affiliation ID value must not use a true/false evaluation to determine if it's valid because 0 will be a valid index but evaluate as false. Thoughts? Thanks, Andy Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu
