Author: toad
Date: 2008-12-18 00:28:29 +0000 (Thu, 18 Dec 2008)
New Revision: 24498
Modified:
branches/db4o/freenet/src/freenet/keys/CHKBlock.java
branches/db4o/freenet/src/freenet/keys/SSKBlock.java
Log:
Refuse to store SSKBlock's and CHKBlock's too, document why.
Modified: branches/db4o/freenet/src/freenet/keys/CHKBlock.java
===================================================================
--- branches/db4o/freenet/src/freenet/keys/CHKBlock.java 2008-12-18
00:27:20 UTC (rev 24497)
+++ branches/db4o/freenet/src/freenet/keys/CHKBlock.java 2008-12-18
00:28:29 UTC (rev 24498)
@@ -115,5 +115,22 @@
public byte[] getRoutingKey() {
return getKey().getRoutingKey();
}
+
+ public boolean objectCanNew(ObjectContainer container) {
+ /* Storing an SSKBlock is not supported. There are some
complications, so lets
+ * not implement this since we don't actually use the
functionality atm.
+ *
+ * The major problems are:
+ * - In both CHKBlock and SSKBlock, who is responsible for
deleting the node keys? We
+ * have to have them in the objects.
+ * - In SSKBlock, who is responsible for deleting the
DSAPublicKey? And the DSAGroup?
+ * A group might be unique or might be shared between very
many SSKs...
+ *
+ * Especially in the second case, we don't want to just copy
every time even for
+ * transient uses ... the best solution may be to copy in
objectCanNew(), but even
+ * then callers to the relevant getter methods may be a worry.
+ */
+ throw new UnsupportedOperationException("Block set storage in
database not supported");
+ }
}
Modified: branches/db4o/freenet/src/freenet/keys/SSKBlock.java
===================================================================
--- branches/db4o/freenet/src/freenet/keys/SSKBlock.java 2008-12-18
00:27:20 UTC (rev 24497)
+++ branches/db4o/freenet/src/freenet/keys/SSKBlock.java 2008-12-18
00:28:29 UTC (rev 24498)
@@ -178,5 +178,22 @@
public byte[] getRoutingKey() {
return getKey().getRoutingKey();
}
+
+ public boolean objectCanNew(ObjectContainer container) {
+ /* Storing an SSKBlock is not supported. There are some
complications, so lets
+ * not implement this since we don't actually use the
functionality atm.
+ *
+ * The major problems are:
+ * - In both CHKBlock and SSKBlock, who is responsible for
deleting the node keys? We
+ * have to have them in the objects.
+ * - In SSKBlock, who is responsible for deleting the
DSAPublicKey? And the DSAGroup?
+ * A group might be unique or might be shared between very
many SSKs...
+ *
+ * Especially in the second case, we don't want to just copy
every time even for
+ * transient uses ... the best solution may be to copy in
objectCanNew(), but even
+ * then callers to the relevant getter methods may be a worry.
+ */
+ throw new UnsupportedOperationException("Block set storage in
database not supported");
+ }
}
_______________________________________________
cvs mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs