Ticket #593 (closed Defect: wontfix)

Opened 7 years ago

Last modified 6 years ago

model objects can not be reused

Reported by: dgf Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.1.3
Keywords: Cc:
Complexity: 5 Area: Application Framework / API
Module: deepamehta-core

Description

This change #574 only introduces a topic reference for update calls and breaks the re-usage of model objects.

In version 4.1 it was possible simply to read a model and use it for the creation of new topics. The entire composite was copied, as in the following (including topic references)

CompositeValueModel model = aRelatingAssociation.getCompositeValue().getModel();
dms.createAssociation(new AssociationModel(.., .., .., model), ...);

I have often used this pattern and it should continue to be supported. With the explicit TopicReferenceModel check in the creation call (in the example above) all topics be rebuild because the returned model uses the RelatedTopicModel class for all topics.

model.getTopic("aSubTopicTypeUri").getClass().getName()

Change History

comment:1 Changed 7 years ago by jri

Oh, that's interesting! I didn't focused that.

Yes, this usage pattern should be supported again.
I'll think about a solution (it's a tricky thing) and will probably fix this soon.

Thank you very much for reporting!

comment:2 Changed 7 years ago by jri

  • Status changed from new to accepted
  • Owner set to jri

comment:3 Changed 6 years ago by jri

  • Milestone Release 4.1.4 deleted

comment:4 Changed 6 years ago by jri

After reconsidering the problem I rather tend to leave the logic as is. I see no reasonable solution.

The underlying problem is complex:

  1. we need the explicit TopicReferenceModel? since we support by-URI-references in requests which update aggregated values. Before that we had only by-ID-references and could use a simple heuristic to distinguish a) references to existing objects from b) models for new objects to be created: if a topic model consists an ID it is a reference. Otherwise it represents a new topic to be created. With URIs on the other hand, this heuristics doesn't work anymore as an URI could be both, a topic reference or the URI of a new topic to be created. That's why the TopicReferenceModel? class was introduced.
  1. OK, no problem you might say. Let the storage layer reconstruct these TopicReferenceModels? when retrieving composite values. But for that the type definitions must be consulted and (due to layer separation) the storage layer has no knowledge about type definitions. OK, then let the next higher layer (the ValueStorage?) morph TopicModels? into TopicReferenceModels? when appropriate. Yes, this would be possible but feels clumsy to me. An alternative solution would be to break the layer separation and move more knowledge into the storage layer. Both solutions doesn't feel reasonable to me.

After all I see the the original use case ("cloning a composite value while reconstructing all the references through reusing a fetched composite value for an subsequent create request") as a rather special case. The benefit of a possible solution mentioned above would not outweigh the compromised layer separation, which possibly come along with a lack of Core maintainability. So I tend to solve this ticket as wontfix.

That's just my current view. What do you think?

comment:5 Changed 6 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.