syncany-team team mailing list archive

[Fabrice Rossi <Fabrice.Rossi@xxxxxxxxxxx>]

Le 05/12/2013 00:05, Philipp Heckel a écrit :
> Go for it. Looks perfectly fine to me. I know that you are not happy with
> the memory consumption, but it'll have to do for now. It would be great to
> have FileContentId, MultiChunkId, etc. all based on ObjectId. I'll merge
> the current state in the master, and you can build on that.

Quick question about that. ChunkEntryId is already almost there, but I'm
a bit puzzled by the getChunkInputStream(byte[] checksum) method from
the MultiChunk class. It's only used by createFile in
FileCreatingFileSystemAction, via getting the checksum from the
ChunkEntryId. My first reflex was to modify the signature of
getChunkInputStream to get directly a ChunkEntryId. But I'm not so sure
if this is the right decision. On the one hand, in database terms,
ChunkEntryId is yet another primary key (in the chunk table) and it used
as a foreign key in other tables, like in the multichunk<->chunk table.
So accessing a chunk via the checksum and not the key seems abstraction
leaking. But on the other hand, a multichunk is really a sort of content
addressed storage, very git like. In then it makes totally sense to be
explicit about how the mapping is done.

Yeah, high level hair splitting, I know ;-) So
getChunkInputStream(ChunkEntryId) or getChunkInputStream(byte[] checksum)?

Cheers,

Fabrice