Morpho

move to 1.6.2

move to 1.7

move to 1.7.1

This should be evident from the bug summary line, but just to clarify: Morpho should be able to handle not only attaching a data table to existing attribute metadata in cases where a data table wasn't previously attached (Matt's description), but also replacing an existing data table with a different one. I imagine the procedure would be largely the same for the replacement case, but with incrementing the revision number in the table id rather than assigning a new id altogether?

Deleting an attached data table (without deleting the attribute metadata) could be useful, but is a lower priority enhancement. Most use cases should be covered by the fact that users can already delete both data table and its metadata, or modify access rules for the data table to make it private.

reassign/target for semtools

"Data->Replace Current Data Table..." presents a dialog where you can select a different local data file.
The file is saved in the Morpho cache, and the following metadata is updated:
-"online" url (with the ecogrid:// prefix)
-object name (set as file name)
-file size in bytes
-number of records (if text file)

Current assumptions:
-you are replacing a nearly identical file (attributes are not checked). mismatches don't cause a failure, but the display is odd (say you have three columns, but the new data only has two, then you see the third column as empty).
-you are not "adding" the data to metadata that was previously there just describing non-existent data.
I need to create a test scenario where we only have descriptions of the data and did not actually import a file. I imagine we can handle this case in the same command.

Notes:
At this point I'm not supporting the manually entered URL for data file references (like you can get with the new data import wizard). This may prove to be an area we wish to improve upon.

Great start! This will be a fantastic enhancement. A couple of comments:

1. When a table is replaced, it would make more sense for Morpho to increment the rev number rather than assign a new docid, as this operation really constitutes 'data revision' rather addition of a new table. (Unless of course this is the first time the data is being attached to existing attribute metadata, if/when that capability is added.)

2. In the Data menu, a user might assume 'Replace Current Data Table..." and "Delete Current Data Table" sound like parallel operations, but they're not. The former replaces only the data, whereas the latter deletes both data and metadata. Perhaps modify the confirmation text for the Delete operation to emphasize that the table and its attribute metadata will be deleted.

for #1:
I've incremented the data file id now.
I have reservations about doing this - especially in a networked environment - since we historically have a horrible time keeping track of where/when doc revisions exist locally and networked.
But since Jing put in all the extra handling to deal with docid conflicts, we may escape unscathed!

(In reply to comment #7)

Great start! This will be a fantastic enhancement. A couple of comments:

1. When a table is replaced, it would make more sense for Morpho to increment
the rev number rather than assign a new docid, as this operation really
constitutes 'data revision' rather addition of a new table. (Unless of course
this is the first time the data is being attached to existing attribute
metadata, if/when that capability is added.)

2. In the Data menu, a user might assume 'Replace Current Data Table..." and
"Delete Current Data Table" sound like parallel operations, but they're not.
The former replaces only the data, whereas the latter deletes both data and
metadata. Perhaps modify the confirmation text for the Delete operation to
emphasize that the table and its attribute metadata will be deleted.

(In reply to comment #8)

I've incremented the data file id now.
I have reservations about doing this - especially in a networked environment -
since we historically have a horrible time keeping track of where/when doc
revisions exist locally and networked.
But since Jing put in all the extra handling to deal with docid conflicts, we
may escape unscathed!

Yeah I thought about this, but there is a precedent for incrementing the rev number insofar as that's how it works when you modify (delimited text) data using the Morpho table editor. As far as I know, the docid conflict resolution step will handle any issues when the document is saved. I've never actually tested it when saving to metacat, but I know it works as expected when you modify a previous version of a table and try to save locally (i.e. changing foo.1.1 and trying to save it when foo.1.2 exists already).

I double checked that the data docid conflict was caught and that you are prompted for action (locally). Still works!

First section of "Data" menu now has these options:
--------------------------
Create/Import New Data Table...
Replace Current Data...
Convert Data to Table...
Delete Current Data Entity
Edit Data Access

changing the Entity Name to match the Object Name. I actually think I'll add at
text field so that you can enter a more descriptive name to the entity if you
wish. Otherwise it's just duplicated information (filename).

"Data->Replace Current Data..." can now be used to add data that has previously only been described.

I believe I've addressed the various permutations described in this bug - reopen as necessary.

At TFRI they brought up a very good point:
Say I duplicate a DP as a means of creating a metadata template - then I replace the data on the copy.
I end up incrementing the data file id - but it's still the old data id in the original DP that I started from.
So now I have the following 2 DPs:
metadata.1.1 with data.1.1
and
metadata.2.1 with data.1.2

There is a conflict now! Either we need an option to make new data ID or we just always make a new data id.

(In reply to comment #8)

for #1:
I've incremented the data file id now.
I have reservations about doing this - especially in a networked environment -
since we historically have a horrible time keeping track of where/when doc
revisions exist locally and networked.
But since Jing put in all the extra handling to deal with docid conflicts, we
may escape unscathed!

(In reply to comment #7)

Great start! This will be a fantastic enhancement. A couple of comments:

1. When a table is replaced, it would make more sense for Morpho to increment
the rev number rather than assign a new docid, as this operation really
constitutes 'data revision' rather addition of a new table. (Unless of course
this is the first time the data is being attached to existing attribute
metadata, if/when that capability is added.)

2. In the Data menu, a user might assume 'Replace Current Data Table..." and
"Delete Current Data Table" sound like parallel operations, but they're not.
The former replaces only the data, whereas the latter deletes both data and
metadata. Perhaps modify the confirmation text for the Delete operation to
emphasize that the table and its attribute metadata will be deleted.

Added a checkbox to specify that a new ID should be generated for the replaced data.
If left unchecked, the data id only has it's revision incremented, but if checked a completely new id is created.

Original Bugzilla ID was 3473