You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by be...@agfa.com on 2006/06/16 16:31:31 UTC
[spec] trying to understand ChangeSummary
Hi all,
I'm trying to get a conceptual understanding of what a ChangeSummary is
and what you can do with it. I hope this is a good place to discuss this.
This is what I think.
/// fairly sure about this
1. A DataGraph is a structured graph of DataObjects
2. A ChangeSummary gives me a list of all DataObjects from my DataGraph
that have changed (including created & deleted)
3. For each DataObject that has changed, I can see what properties have
changed and can access the old and new value
/// less sure
4. In case non-datatype properties have changed, the old value is the
reference the object had before change tracking started. The contents of
the DataObject that is referred to can have changed.
For instance suppose I have the graph containing three data objects (for
simplicity all of the same type):
A(name=a) -> B(name=b) -> C(name = c)
where arrows indicate non-datatype properties and name is a string
property. If this graph is changed into
A(name=a) -> C(name=cc) -> B(name = bb)
Then all three objects will have changed. For object A, one property has
changed: the reference (B -> C). If I ask the changesummary for the old
value of the reference I get a reference to B whose name is equal to bb.
This might seem a bit strange because in the old days, A referred to B
with name=b.
/// even less sure
5. Suppose I now want to make an update service that uses the
ChangeSummary to update my back-end datastore.
Then, the only way I can think of that makes ChangeSummary useful is
either when
1. I have implementation specific identifier properties are
associated with each type [for instance by giving each of my DataObject
types a URI property]
or
2. The structure of my DataGraph (i.e. the links between the
various DataObjects) can't change
Am I off track? Any comments welcome,
Bert
PS: I'm not always as clear as I want to be... so if I need to clarify
something, I'll be happy to!
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [spec] trying to understand ChangeSummary
Posted by Frank Budinsky <fr...@ca.ibm.com>.
This is a discussion currently going on among the spec collaboration
group. It looks like the SDO 2.1 spec will probably introduce something
like what you're suggesting.
Frank.
bert.robben@agfa.com wrote on 06/19/2006 03:49:44 AM:
> Thanks Frank, that makes things much clearer.
>
> Does anyone have any idea why there is no standard mechanism to declare
a
> property of a certain type as being the "identifier" property? If your
> type is created from an XSD, you can declare certain attributes to be
> ID's. Then the SDO implementation needs to keep track of this because
> sdo-refs should use that property instead of an SDO xpath expression.
But
> I don't understand why this is not visiable in the SDO metamodel.
>
> Bert
>
>
>
>
> Frank Budinsky <fr...@ca.ibm.com>
> 16/06/2006 21:04
> Please respond to
> tuscany-user@ws.apache.org
>
>
> To
> tuscany-user@ws.apache.org
> cc
>
> Subject
> Re: [spec] trying to understand ChangeSummary
>
>
>
>
>
>
> Hi Bert,
>
> > I'm trying to get a conceptual understanding of what a ChangeSummary
is
> > and what you can do with it. I hope this is a good place to discuss
> this.
>
> Since there's no public forum for discussing the SDO spec (although
there
> probably should be) and since Tuscany is an open source implementation
of
> SDO, I guess we're your only public choice :-)
>
> > 1. A DataGraph is a structured graph of DataObjects
>
> right.
>
> > 2. A ChangeSummary gives me a list of all DataObjects from my
DataGraph
> > that have changed (including created & deleted)
>
> right.
>
> > 3. For each DataObject that has changed, I can see what properties
have
> > changed and can access the old and new value
>
> right.
>
> > 4. In case non-datatype properties have changed, the old value is the
> > reference the object had before change tracking started. The contents
of
>
>
> > the DataObject that is referred to can have changed.
> > For instance suppose I have the graph containing three data objects
(for
>
>
> > simplicity all of the same type):
> >
> > A(name=a) -> B(name=b) -> C(name = c)
> >
> > where arrows indicate non-datatype properties and name is a string
> > property. If this graph is changed into
> >
> > A(name=a) -> C(name=cc) -> B(name = bb)
> >
> > Then all three objects will have changed. For object A, one property
has
>
>
> > changed: the reference (B -> C). If I ask the changesummary for the
old
> > value of the reference I get a reference to B whose name is equal to
bb.
>
>
> > This might seem a bit strange because in the old days, A referred to B
> > with name=b.
>
> you're right, but the basic idea is that it gives you the object it used
> to point to. If that object itself has changed you need to look at the
> ChangeSummary's old values for its properties as well.
>
> > 5. Suppose I now want to make an update service that uses the
> > ChangeSummary to update my back-end datastore.
> >
> > Then, the only way I can think of that makes ChangeSummary useful is
> > either when
> > 1. I have implementation specific identifier properties are
> > associated with each type [for instance by giving each of my
DataObject
> > types a URI property]
> > or
> > 2. The structure of my DataGraph (i.e. the links between the
> > various DataObjects) can't change
>
> I'm not an expert on how people implement DAS's, but I think approach #1
> is the common way to correlate. Maybe someone with more DAS knowledge
can
> comment.
>
> I hope this helps.
> Frank
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [spec] trying to understand ChangeSummary
Posted by be...@agfa.com.
Thanks Frank, that makes things much clearer.
Does anyone have any idea why there is no standard mechanism to declare a
property of a certain type as being the "identifier" property? If your
type is created from an XSD, you can declare certain attributes to be
ID's. Then the SDO implementation needs to keep track of this because
sdo-refs should use that property instead of an SDO xpath expression. But
I don't understand why this is not visiable in the SDO metamodel.
Bert
Frank Budinsky <fr...@ca.ibm.com>
16/06/2006 21:04
Please respond to
tuscany-user@ws.apache.org
To
tuscany-user@ws.apache.org
cc
Subject
Re: [spec] trying to understand ChangeSummary
Hi Bert,
> I'm trying to get a conceptual understanding of what a ChangeSummary is
> and what you can do with it. I hope this is a good place to discuss
this.
Since there's no public forum for discussing the SDO spec (although there
probably should be) and since Tuscany is an open source implementation of
SDO, I guess we're your only public choice :-)
> 1. A DataGraph is a structured graph of DataObjects
right.
> 2. A ChangeSummary gives me a list of all DataObjects from my DataGraph
> that have changed (including created & deleted)
right.
> 3. For each DataObject that has changed, I can see what properties have
> changed and can access the old and new value
right.
> 4. In case non-datatype properties have changed, the old value is the
> reference the object had before change tracking started. The contents of
> the DataObject that is referred to can have changed.
> For instance suppose I have the graph containing three data objects (for
> simplicity all of the same type):
>
> A(name=a) -> B(name=b) -> C(name = c)
>
> where arrows indicate non-datatype properties and name is a string
> property. If this graph is changed into
>
> A(name=a) -> C(name=cc) -> B(name = bb)
>
> Then all three objects will have changed. For object A, one property has
> changed: the reference (B -> C). If I ask the changesummary for the old
> value of the reference I get a reference to B whose name is equal to bb.
> This might seem a bit strange because in the old days, A referred to B
> with name=b.
you're right, but the basic idea is that it gives you the object it used
to point to. If that object itself has changed you need to look at the
ChangeSummary's old values for its properties as well.
> 5. Suppose I now want to make an update service that uses the
> ChangeSummary to update my back-end datastore.
>
> Then, the only way I can think of that makes ChangeSummary useful is
> either when
> 1. I have implementation specific identifier properties are
> associated with each type [for instance by giving each of my DataObject
> types a URI property]
> or
> 2. The structure of my DataGraph (i.e. the links between the
> various DataObjects) can't change
I'm not an expert on how people implement DAS's, but I think approach #1
is the common way to correlate. Maybe someone with more DAS knowledge can
comment.
I hope this helps.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [spec] xml representation of ChangeSummary
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Bert,
This is part of the spec that IMO still needs a lot of work. Currently,
the spec doesn't really give a clear description of the change summary
serialization (not just the created objects), so implementations are
unlikely to interoperate. Right now, the Tuscany implementation doesn't
serialize the created objects ("create" attribute) at all, since the value
can be deduced from the serialized object changes (i.e., a parent
containment reference getting a new object that isn't also removed frorm
some other containment reference in the graph). Earlier, when we did
serialize it, we used a " " separator.
But, like I said, the spec is going to need to address this issue and
clearly define the standard serialization format before we will have
implementation interoperability.
Frank.
bert.robben@agfa.com wrote on 06/19/2006 03:50:38 AM:
> I've another q on the spec of ChangeSummary.
>
> The spec says:
>
> DataObjects which are currently in the data graph, but were not
> present when logging was started
> are indicated in the change summary with a create attribute
>
> <changeSummary create="E0004" >
> </changeSummary>
> ...
> <employees name="Al
>
> All nice and well, but what if there is more than one object created? Do
> you do it comma-separated then (just a plain guess) ? Or even worse, is
it
> up to the implementation to do something nice ...
>
> <changeSummary create="E0004,E005,E006"
> delete="#/a/b,E005,#/c/d/e" >
>
>
> Any idea why this is so underspecified, or did I miss something in the
> spec?
>
> Bert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
[spec] xml representation of ChangeSummary
Posted by be...@agfa.com.
I've another q on the spec of ChangeSummary.
The spec says:
DataObjects which are currently in the data graph, but were not
present when logging was started
are indicated in the change summary with a create attribute
<changeSummary create="E0004" >
</changeSummary>
...
<employees name="Al
All nice and well, but what if there is more than one object created? Do
you do it comma-separated then (just a plain guess) ? Or even worse, is it
up to the implementation to do something nice ...
<changeSummary create="E0004,E005,E006"
delete="#/a/b,E005,#/c/d/e" >
Any idea why this is so underspecified, or did I miss something in the
spec?
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [spec] trying to understand ChangeSummary
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Bert,
> I'm trying to get a conceptual understanding of what a ChangeSummary is
> and what you can do with it. I hope this is a good place to discuss
this.
Since there's no public forum for discussing the SDO spec (although there
probably should be) and since Tuscany is an open source implementation of
SDO, I guess we're your only public choice :-)
> 1. A DataGraph is a structured graph of DataObjects
right.
> 2. A ChangeSummary gives me a list of all DataObjects from my DataGraph
> that have changed (including created & deleted)
right.
> 3. For each DataObject that has changed, I can see what properties have
> changed and can access the old and new value
right.
> 4. In case non-datatype properties have changed, the old value is the
> reference the object had before change tracking started. The contents of
> the DataObject that is referred to can have changed.
> For instance suppose I have the graph containing three data objects (for
> simplicity all of the same type):
>
> A(name=a) -> B(name=b) -> C(name = c)
>
> where arrows indicate non-datatype properties and name is a string
> property. If this graph is changed into
>
> A(name=a) -> C(name=cc) -> B(name = bb)
>
> Then all three objects will have changed. For object A, one property has
> changed: the reference (B -> C). If I ask the changesummary for the old
> value of the reference I get a reference to B whose name is equal to bb.
> This might seem a bit strange because in the old days, A referred to B
> with name=b.
you're right, but the basic idea is that it gives you the object it used
to point to. If that object itself has changed you need to look at the
ChangeSummary's old values for its properties as well.
> 5. Suppose I now want to make an update service that uses the
> ChangeSummary to update my back-end datastore.
>
> Then, the only way I can think of that makes ChangeSummary useful is
> either when
> 1. I have implementation specific identifier properties are
> associated with each type [for instance by giving each of my DataObject
> types a URI property]
> or
> 2. The structure of my DataGraph (i.e. the links between the
> various DataObjects) can't change
I'm not an expert on how people implement DAS's, but I think approach #1
is the common way to correlate. Maybe someone with more DAS knowledge can
comment.
I hope this helps.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org