Multiple changes to same topic not handled correctly #30

Closed
GoogleCodeExporter opened this Issue Mar 16, 2015 · 9 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter
If more than one change has been made to the same topic since the last 
update DB2TM only looks at the last change, which can cause problems. For 
example, a delete followed by a reinsert will be interpreted as an insert, 
causing data to be duplicated.

A fix was attempted in January 2009, but the customer says they have tried 
the latest version, and while this gives no error messages, the topic that 
should change type has stayed with the older type. (It has just one type.) 

Original issue reported on code.google.com by lar...@gmail.com on 26 Jun 2009 at 11:11

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Any progress on this issue? 

Original comment by ljant...@gmail.com on 5 Aug 2009 at 8:01

Any progress on this issue? 

Original comment by ljant...@gmail.com on 5 Aug 2009 at 8:01

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Geir Ove will look at it this week.

Original comment by lar...@gmail.com on 5 Aug 2009 at 12:30

Geir Ove will look at it this week.

Original comment by lar...@gmail.com on 5 Aug 2009 at 12:30

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

The problem is that we have a <topic type="#type"> definition that is not 
primary. 
Primary topic entities will not have their topic types replaced at the moment. 
Instead any given types will be added to the list of topic types. This is not 
really 
very useful. To get around this limitation I do think that we have to say 
something 
about which topic types should get replaced (to avoid having any primary topic 
types 
replaced).

Example:

<topic type="#type" replace-types="fd:organisasjonsenhet">

If we added support for the replace-types attribute, which takes a topic 
reference, 
to the <topic> element then DB2TM would be able to replace topic types that 
were 
instances of the type given in the replace-types attribute, even though the 
topic 
entity is not primary.

Original comment by indiapaleale@gmail.com on 14 Aug 2009 at 11:58

The problem is that we have a <topic type="#type"> definition that is not 
primary. 
Primary topic entities will not have their topic types replaced at the moment. 
Instead any given types will be added to the list of topic types. This is not 
really 
very useful. To get around this limitation I do think that we have to say 
something 
about which topic types should get replaced (to avoid having any primary topic 
types 
replaced).

Example:

<topic type="#type" replace-types="fd:organisasjonsenhet">

If we added support for the replace-types attribute, which takes a topic 
reference, 
to the <topic> element then DB2TM would be able to replace topic types that 
were 
instances of the type given in the replace-types attribute, even though the 
topic 
entity is not primary.

Original comment by indiapaleale@gmail.com on 14 Aug 2009 at 11:58

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Hmmm. Adding a replace-types attribute sounds very ad-hoc. It seems to me that 
users 
are unlikely to pick up on this one, and that they will only add this kind of 
attribute after they run into problems and are told to fix it this way by us. I 
would feel better about this if we could come up with some more general 
solution.

I'm not sure I understand why this limitation is there in the first place. Why 
can't 
we change the topic type if the topic element is not primary?

Original comment by lar...@gmail.com on 14 Aug 2009 at 12:15

Hmmm. Adding a replace-types attribute sounds very ad-hoc. It seems to me that 
users 
are unlikely to pick up on this one, and that they will only add this kind of 
attribute after they run into problems and are told to fix it this way by us. I 
would feel better about this if we could come up with some more general 
solution.

I'm not sure I understand why this limitation is there in the first place. Why 
can't 
we change the topic type if the topic element is not primary?

Original comment by lar...@gmail.com on 14 Aug 2009 at 12:15

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Well, that is a good question. :)

I guess there is not really any reason to treat the types of a topic any 
different 
than its other characteristics. 

Replacing the topic type would work in this particular case, but we might run 
into 
issues if there were two different tables that reference the same topic and 
assign 
them different topic types. What do you think?

Original comment by indiapaleale@gmail.com on 14 Aug 2009 at 12:33

Well, that is a good question. :)

I guess there is not really any reason to treat the types of a topic any 
different 
than its other characteristics. 

Replacing the topic type would work in this particular case, but we might run 
into 
issues if there were two different tables that reference the same topic and 
assign 
them different topic types. What do you think?

Original comment by indiapaleale@gmail.com on 14 Aug 2009 at 12:33

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

I've thought about this and it seems to me that the general issue is that of 
what to 
do when statements of a specific type are spread over different tables. 
Usually, 
that just doesn't happen. For the type it's conceivable that it might happen 
(because it's one kind of statement that really might occur in different 
places), 
but then again we generally consider multi-typing topics to be a bad thing and 
don't 
encourage it.

So it seems to me that if we treated the topic type the same way as other 
statements 
then we'd solve this problem, and most likely we would not create a new one. If 
we 
did create a new one it would probably a pretty obscure issue, and we could 
come up 
with an ad-hoc solution at that point (because for really obscure issues ad-hoc 
solutions can be defensible).

Does that make sense?

Original comment by lar...@gmail.com on 14 Aug 2009 at 10:18

I've thought about this and it seems to me that the general issue is that of 
what to 
do when statements of a specific type are spread over different tables. 
Usually, 
that just doesn't happen. For the type it's conceivable that it might happen 
(because it's one kind of statement that really might occur in different 
places), 
but then again we generally consider multi-typing topics to be a bad thing and 
don't 
encourage it.

So it seems to me that if we treated the topic type the same way as other 
statements 
then we'd solve this problem, and most likely we would not create a new one. If 
we 
did create a new one it would probably a pretty obscure issue, and we could 
come up 
with an ad-hoc solution at that point (because for really obscure issues ad-hoc 
solutions can be defensible).

Does that make sense?

Original comment by lar...@gmail.com on 14 Aug 2009 at 10:18

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Yes, that makes sense, and I do agree with you. Lets remove the 
Entity.isPrimary 
check in the code so that all topics get their topic type replaced when changed.

Original comment by indiapaleale@gmail.com on 16 Aug 2009 at 7:58

Yes, that makes sense, and I do agree with you. Lets remove the 
Entity.isPrimary 
check in the code so that all topics get their topic type replaced when changed.

Original comment by indiapaleale@gmail.com on 16 Aug 2009 at 7:58

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

This issue was closed by revision r416.

Original comment by indiapaleale@gmail.com on 17 Aug 2009 at 9:05

  • Changed state: Fixed
This issue was closed by revision r416.

Original comment by indiapaleale@gmail.com on 17 Aug 2009 at 9:05

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 16, 2015

Original comment by lar...@gmail.com on 1 Sep 2009 at 11:20

  • Added labels: Release5.0.1

Original comment by lar...@gmail.com on 1 Sep 2009 at 11:20

  • Added labels: Release5.0.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment