[hibernate-dev] some simple questions for Search dev

[Emmanuel Bernard]

On  Jun 4, 2008, at 18:06, Sanne Grinovero wrote:

> Hello,
> I need some suggestion to name new parameters in H.Search;
>
> I'm implementing the parameter for FSMasterDirectoryProvider and
> FSSlaveDirectoryProvider to select an appropriate "chunk size":
> the amount of bytes to have java.nio attempt to transfer at once;
> (we have to limit it as huge files blow it: 2GB on linux,
> 100MB on windows 32bit, don't know on windows 64bit)
> I defaulted to a very conservative 16MB (ok?)
> and the patch is really trivial but:
>
> A)I need a good and intuitive name for the parameter:
> I have "copyChunkSizeMB" currently in my code,
> I don't like it but couldn't think of a better alternative.
> The result would be "hibernate.search.[indexname].copyChunkSizeMB"...
> something better that gives the idea?
> I thought of "blockSize" but that isn't really a block size, but  
> gives the idea
> as people could be more familiar with it. "copyBlockSizeMB"?
> I'll have to document the chosen name, so I think it won't
> be easy to change it later.

chunkSizeOnCopy
bufferSizeOnCopy
memoryBufferOnCopy

I would not add MB as no property has the units in its name so far.

>
>
> B)Units for the previous param?
> chosing bytes is not very practical: final user would
> certainly need to open his calcluator;
> MB is probably the choice but means people can't select chunks below  
> the MB,
> which would be silly anyway IMHO.

MB is good

>
>
> C)The "smart" parameter: current FileHelper has a really
> cool feature called "smart" which is currently always enabled,
> it does something similar to rsync checking timestamps & file
> sizes to skip copying some files.
> there's a TODO in both Master&Slave Dir.Providers to make it
> a configurable parameter (which means having the option
> to disable it).
> I just need you to confirm the TODO is still valid.
> Name? "enableSmartCopy" ? (default true)

No we should remove the todo. I did it in case people did not like it  
or if it was unreliable. It turned out to be good and nobody wants the  
dumb version.

>
>
> thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev