References to XMLDatastreamObjects being overwritten

[rvpeters]

I am building a project with multiple DigitalObject models and I have added a few of my own XmlDatastreams using my personal XML Schemas. What I ended up doing was copying dc.py and modifying it so there was one for each XML Schema. It appears to work on an individual basis, however when I have multiple declarations within my models.py Django project, it is pointing all of the XMLDatastreamObjects to the last declared one. For example:

class FileObject(DigitalObject):
FILE_CONTENT_MODEL = 'info:fedora/genrepo:File-1.0'
CONTENT_MODELS = [ FILE_CONTENT_MODEL ]
file = FileDatastream("FILE", "Binary datastream", defaults={
'versionable': True,
})
extra_meta = XmlDatastream("EXTRA_META, "Extra Metadata", ExtraMetaXML)
second_meta = XmlDatastream("SECOND_META", "Second Metadata", SecondMetaXML)

class AnotherObject(DigitalObject):
CONTENT_MODELS = ['info:fedora/%s:ResultsObject' % FEDORA_PIDSPACE]
third_meta = XmlDatastream("THIRD_META", "Third Metadata", ThirdMetaXML)

Using this models.py, both first_meta, second_meta, and third_meta all show up as ThirdMetaXML objects when declaring a new FileObject or AnotherObject (obj.first_meta.content, etc). Commenting out third_meta declaration in models.py makes the remaining two SecondMetaXML.

Am I declaring these XmlDatastreams properly in the models.py or is there another way these datastreams should be declared?

[rvpeters]

I managed to finally fix the issue by adding a "defaults" section to each of the XmlDatastream declaration (running eulfedora_0.21). Without the "defaults" declaration, adding additional XmlDatastreams results in the references being overwritten, as described in the earlier issue description.

I would be interested to see if this problem is reproducable by anyone else or if it is a problem that is confined to my specific situation.

[rlskoeser]

@rvpeters11 thanks for the feedback.

You can see some of our sample datastream declarations here:
https://github.com/emory-libraries/OpenEmory/blob/master/openemory/publication/models.py#L1013

It sounds like you may have discovered a bug - perhaps we never happened on it because we always specify defaults. I'll try to see if we can reproduce it to confirm.

[rlskoeser]

I've been going through the landscape.io report on eulfedora code, and I'm fairly certain that this is due to the use of a mutable parameter (i.e., a dictionary) as a default value (I had to read the important warning on default values. So, I think this code clean up should fix it, and it'll be resolved in the next release.