Changes between Version 1 and Version 2 of syntheticData


Ignore:
Timestamp:
01/15/2010 06:15:42 PM (9 years ago)
Author:
jbecla
Comment:

updated based on discussion at DataAcc? telecon Jan 15, 2010

Legend:

Unmodified
Added
Removed
Modified
  • syntheticData

    v1 v2  
    33[wiki:LSSTDatabase LSST Database] 
    44 
    5 In DC3b, we need to support synthetic data - it means we will inject at pixel level some fictitious "sources" in order to verify how well pipelines are able detect them.  
     5No need to support any of this in DC3b 
    66 
    7 This is an early draft, to be discussed. 
     7Synthetic data = inject at pixel level some fictitious "sources" in order to verify how well pipelines are able detect them.  
    88 
    99 
    1010When synthetic sources are injected, information about them will be recorded in a place inaccessible to users and pipeline developers. Only these with appropriate privileges will be able to access this information. This information will likely be stored in a special Source table, and the schema will likely be a superset of LSST Source table schema + imageSim schema. 
    1111 
     12We need to use association pipeline to to match information about the synthetic sources with the Source catalog produced by LSST pipelines. 
    1213 
    13 We need to decide how to match information about the synthetic sources with the Source catalog produced by LSST DC3b pipelines? Perhaps we should use our association pipeline? 
     14Important issues: 
     15 * we need to quarantine synthetic sources from the lsst science db, can't leak them there. Current thinking: any image that is touched by synthetic sources will have a non-polluted copy. We will do separate runs to process images containing synthetic sources 
     16 * we need to hide info about synthetic sources from users. 
    1417 
    1518 
     
    2124 
    2225It might be a good idea to introduce a common prefix, we will need it for later, eg for restricting access to level 3 and level 4 data. 
     26 
     27Potentially useful (from KT): 
     28{{{ 
     29#!sql 
     30GRANT USAGE ON *.* TO 'user'@'%' 
     31GRANT SELECT ON `%`.* TO 'user'@'%' 
     32GRANT SHOW VIEW ON `test`.* TO 'user'@'%' 
     33}}} 
     34 
     35Note the % instead of *.  This puts this grant in the mysql.db table instead of the mysql.user table. 
     36 
     37This actually removes all privileges except SHOW VIEW from the user for the test database, since this grant is more specific than the previous one.  In particular, it removes the SELECT privilege.  Unfortunately, it doesn't look like it's possible to turn off *all* privileges in this manner without direct updating of the mysql.db table.  SHOW VIEW seems to be the least intrusive one.  Still more unfortunately, as long as the user has *any* privilege for a database, it appears that the user can see that database in SHOW DATABASES, can USE that database, and can even SHOW TABLES inside it.