An Issue with Replication
1 view
Skip to first unread message
Borislav
Feb 10, 2009, 11:57:35 AM2/10/09
to HyperGraphDB
Hi Cipri,
There's an annoying issue with the replication that I apologize to
have overlooked the first time I looked at the code. When an atom is
replicated in the current setup, both the logging DB and the peer DBs
assume two things that are potentially incorrect: (1) the type of the
atom is the default HGAtomType for the Java class of the atom's
runtime instance and (2) they already have that atom type stored
locally.
Actually since transfer to peer happens with a layout subgraph, the
type handle is copied along with the layout and peers don't assume
(1), but log DBs do I think.
In addition, theoretically, a peer may have the atom type, but a
different version of it (say missing some new bean property or
something). So that's another problem to solve :)
I don't have solution for now for those problems, but we should
discuss...
Best,
Boris
There's an annoying issue with the replication that I apologize to
have overlooked the first time I looked at the code. When an atom is
replicated in the current setup, both the logging DB and the peer DBs
assume two things that are potentially incorrect: (1) the type of the
atom is the default HGAtomType for the Java class of the atom's
runtime instance and (2) they already have that atom type stored
locally.
Actually since transfer to peer happens with a layout subgraph, the
type handle is copied along with the layout and peers don't assume
(1), but log DBs do I think.
In addition, theoretically, a peer may have the atom type, but a
different version of it (say missing some new bean property or
something). So that's another problem to solve :)
I don't have solution for now for those problems, but we should
discuss...
Best,
Boris
Ciprian Costa
Feb 10, 2009, 3:54:29 PM2/10/09
to hyperg...@googlegroups.com
Hi Boris
When implementing we decided to assume that everyone has all the type information and later on we can figure out how to distribute it. What I did for my test programs is add the types to all the dbs with the same handle (just like for the well known types that you have.
About versioning, I think that if you introduce incompatible versions of objects, we need to create a different type for them. It would be interesting if the query mechanism could handle different versions of the same class (and should not be that difficult given the generic representation). Recreating the objects in memory would be a different thing though, and should assume a certain level of compatibility between versions.
About logging, I was thinking to change the mechanism. It was the easiest choice, but somehow does not feel right.
For the last days I was looking over the code (in the little time I have in the evening) and was pondering which items are a priority. Do you have a list of your own? One thing is the workflow based conversations that could be refactored (I agree with your previous email that I did not get to answer yet).
Regards,
Cipri
When implementing we decided to assume that everyone has all the type information and later on we can figure out how to distribute it. What I did for my test programs is add the types to all the dbs with the same handle (just like for the well known types that you have.
About versioning, I think that if you introduce incompatible versions of objects, we need to create a different type for them. It would be interesting if the query mechanism could handle different versions of the same class (and should not be that difficult given the generic representation). Recreating the objects in memory would be a different thing though, and should assume a certain level of compatibility between versions.
About logging, I was thinking to change the mechanism. It was the easiest choice, but somehow does not feel right.
For the last days I was looking over the code (in the little time I have in the evening) and was pondering which items are a priority. Do you have a list of your own? One thing is the workflow based conversations that could be refactored (I agree with your previous email that I did not get to answer yet).
Regards,
Cipri
Reply all
Reply to author
Forward
0 new messages