| train uniqueness constraint II [message #942] |
Wed, 26 June 2013 10:10  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Dear group,
once more, we have a problem with the uniqueness constraint for <train>
elements
"The compound of the attributes trainNumber, additionalTrainNumber and
scope has to be unique for all <train> elements. If some of these
attributes is absent the others have to be unique. The code attribute is
used for some unique string identifying the train regardless of the
unique attribute triple."
We would like to transmit the same train twice: once in processStatus
_planned_, once in state _changed_. I think this should be allowed, so I
would ask the specification text to be changed to
"The compound of the attributes trainNumber, additionalTrainNumber,
scope and processStatus ....
Best,
--Andreas.
|
|
|
|
| Re: train uniqueness constraint II [message #944 is a reply to message #942] |
Fri, 19 July 2013 17:55  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Andreas and all others,
I understand the wish to transmit the same train for several process
status. From the first view, there should be no objection against
extending the primary key of <trains> with the attribute processStatus.
First - by the way - it is already possible to do what you need: Add the
train twice, one with processStatus=planned, the other with
processStatus=changed; give one the additionalTrainNumber=1 and the oder
additionalTrainNumber=2, both with scope=primary. Simply select the next
available additionalTrainNumber if you want to add a new "version" of a
train.
However, there is a need to move the attribute processStatus from <train>
either to <trainPartSequence> or <trainPart>: A train can be "ordered" at
one section and "changed" or anything else at another section. This
normally happens with trains operating via several IMs.
So if possibly processStatus has moved to <trainPartSequence> in a future
version, it would not be available for the primary key anymore.
There are several possible options for that, e. g.:
a) To extend the primary key of <train> with processStatus and
additionally to introduce a new processStatus at either
<trainPartSequence> or <trainPart>. This would fulfill all needs but it
may be treated as too complicated: There may be conflicts between the
concurring processStatus.
b) To move the processStatus to either <trainPartSequence> or <trainPart>,
leave the primary key of <trains> as it is (w/o processStatus) and use the
attribute additionalTrainNumber (with scope=primary) to distinguish
between the status you wanted.
Dear Joachim as the coordinator - what do you think? Please note that from
now on we have two wishes in this thread: (1) the possible extension of
the primary key with processStatus and (2) to move or reintroduce
processStatus to <trainPartSequence> or <trainPart>.
With best regards,
Dirk.
---
Am 26.06.2013, 10:10 Uhr, schrieb Andreas Tanner <ata(at)ivude>:
> Dear group,
>
> once more, we have a problem with the uniqueness constraint for <train>
> elements
>
> "The compound of the attributes trainNumber, additionalTrainNumber and
> scope has to be unique for all <train> elements. If some of these
> attributes is absent the others have to be unique. The code attribute is
> used for some unique string identifying the train regardless of the
> unique attribute triple."
>
> We would like to transmit the same train twice: once in processStatus
> _planned_, once in state _changed_. I think this should be allowed, so I
> would ask the specification text to be changed to
>
> "The compound of the attributes trainNumber, additionalTrainNumber,
> scope and processStatus ....
>
> Best,
> --Andreas.
|
|
|
|
Members
Search
Help
Login
Home
