syncany-team team mailing list archive
-
syncany-team team
-
Mailing list archive
-
Message #00597
Re: Long ids
Hi Fabrice,
> The ChunkEntry is only the database representation, right?
Yes, ChunkEntry is only database representation, so the actual data is
missing, unlike the object in the "chunk" package.
>
> Hum, but if the ChunkEntry and the Chunk both contains the checksum
> which is the Id of the Chunk, why do we need a ChunkEntryId is the first
> place?
The ChunkEntryId only exists because this is needed for the "quick
access" caches in the Database and DatabaseVersion classes. We need a
ChunkEntryId, because "byte[]" cannot be used as key in a Map:
// Quick access cache
private Map<ChunkEntryId, MultiChunkEntry> chunkMultiChunkCache;
> Or to put it differently, why not replacing the byte[] in
> ChunkEntry and Chunk by a ChunkId?
That I don't really know. We could do that, but only if it's clear from
the code that for ChunkEntry objects the identifier is a checksum. Maybe
the Id for chunks should be named ChunkChecksum to make this clearer
(and the ID scheme more complex :-)).
ChunkEntry and Chunk should not have the same IDs because they are in
different packages. These packages should not cross-reference each other.
> I'm asking because if you want to keep getChunkInputStream(byte[])
> (which totally makes sense), then the ChunkEntryId must leek its
> internal representation (as a byte[]). So either it's a getCheckSum
> specific to ChunkEntryId, so far so good, or it's a general method of
> ObjectId. I would refrain from using the latter solution, because it
> will be inefficient for tight memory representation of short ids. Not a
> big deal, again. Also if you go for Gregor's solution (or a variant of
> it), it would mean putting getByteArray in the ObjectId which again is
> not so beautiful.
I don't see any reason for the "org.syncany.chunk.*" classes to
introduce an ID concept, so having a getChunkInputString(ObjectId)
method would not be sensible. Following the argumentation of above, it
is hence necessary to leak the internal representation to call the
getChunkInputString(byte[]) method.
Hope this makes sense :-)
Best
Philipp
References