David, Thanks to your feedback I have performed the following tasks and pushed them to the metadata branch:
On Fri, Jul 9, 2010 at 10:39 AM, David Winslow <[email protected]> wrote: > [...] > > There's some left-overs floating around: > * models.py imports uggettext as _ and later overrides it with "def _(x): > return x" > fixed. > * extra gn.login/logout around the main loop in LayerManager.slurp() > (side note - it would be nice to avoid logging in/out repeatedly for this; > that's tripling the number of HTTP requests we have to make to GeoNetwork in > a slurp()) > Geonetwork object is now being cached like the gs_catalog. * the LabelledInput class from forms.py is no longer needed > removed. > Layer has a many-to-many relationship with Contacts. I seem to remember > discussing using two foreign-key fields to accomplish that, since the schema > we got from the World Bank specifies that a metadata document contains > exactly one owner and one metadata maintainer. Did I miss something? > You are correct we discussed using two foreign-key fields, but I felt strongly inclined towards the many-to-many option while implementing the Role model and that's why I sent that mail before with the breakdown of the models. I have double checked with Galen and more than two contacts can be attached, the schema specifies those two contacts as a minimum. The API I implemented allows accessing the poc and metadata_author objects as layer properties so the use is not complicated by having the more liberal many-to-many relationship and we get the benefit of being able to use the layer/contact/role/permission architecture to allow some level of per-object permissions based on the contact role. SUPPLEMENTAL has two P's in English (let's try to keep the API spelled > correctly so orthography nerds like me don't flip out.) > (DEFAULT_SUPLEMENTAL_INFORMATION) > Fixed, mea culpa. > It also seems a little odd that accessing a layer's metadata information > (poc) may have the side-effect of creating a Contact in the database. I > would think it would be better to just leave it alone if no poc is > configured. The default value should also probably be pulling an existing > user rather than making one from scratch. Maybe the admin user with the > lowest user-id would work? Or we can just require admins to create a > superuser and put the id in settings.py. > Fixed by adding a initial_data.json fixture with the two default contacts and changing the get_or_create to a simple get > > I don't think we should merge this onto master before addressing these > issues. > We are one step closer now :) Ariel.
