Re: Issue 428 in arctos: sitemaps still contain MVZ page junk
arc...@googlecode.com
Comment #2 on issue 428 by lkvoong: sitemaps still contain MVZ page junk
http://code.google.com/p/arctos/issues/detail?id=428
MVZ Page and Img data copied to FLAT_IMG_PAGE table and deleted from FLAT.
Data
still exists in Arctos base tables, but both collections are not public.
Need a way
to comprehensively remove collections.
arc...@googlecode.com
Comment #3 on issue 428 by dust...@gmail.com: sitemaps still contain MVZ
page junk
http://code.google.com/p/arctos/issues/detail?id=428
To finish this, we need to
1) get everything that was GREFfed entered as Arctos Media
2) get any useful data from gref moved to TAGs
Removing collections will (hopefully) be a rare occurrence; do it by e.g.,
sql scripts that we keep around somewhere.
arc...@googlecode.com
Cc: lkvo...@gmail.com koomap...@gmail.com
Comment #4 on issue 428 by dust...@gmail.com: sitemaps still contain MVZ
page junk
http://code.google.com/p/arctos/issues/detail?id=428
Issue 313 has been merged into this issue.
arc...@googlecode.com
Comment #5 on issue 428 by dust...@gmail.com: sitemaps still contain MVZ
page junk
http://code.google.com/p/arctos/issues/detail?id=428
Gref relationships were partially formed to table keys, but those keys were
not always to the correct tables and constraints were never created, so the
tables have changed, and partially by string matches to data. The Media are
presumably still on some UCB server.
Arctos is not going to serve as an indefinite archival trashcan.
IMG and PAGE Data from (historic version of) table FLAT and all gref tables:
GREF_USER
GREF_ROI_VALUE_NG
GREF_ROI_NG
GREF_REFSET_ROI_NG
GREF_REFSET_NG
GREF_PAGE_REFSET_NG
exported to CSV and emailed to Carla, archived on lily.mip.berkeley.edu
GREF user and data dropped.