Closed GoogleCodeExporter closed 9 years ago
Do you specify LegacySupport.TypeResolver as the 3rd parameter to the
BinaryFile.Open() ?
Original comment by yuriastrakhan
on 23 Feb 2012 at 6:23
No I hadn't - I was trying to make the code drop in compatible with the patch,
but the legacy resolver seems like a good idea - perhaps the legacy resolver
should be used by default in the FastBinFileUtil? Or for the purposes of clean
separation, I can certainly update my references, it was just safer to do in
the library.
Original comment by kar...@gmail.com
on 23 Feb 2012 at 6:29
I would rather have a clear separation - the legacy lib was created
specifically so i can move away any obsolete code, so the users can always
choose to either support the legacy data files with the type mapping, or
migrate them with a one time conversion and remove any legacy dependecies.
UtcDateTime and UniformDataFiles seem to be a dead-end path.
Original comment by yuriastrakhan
on 23 Feb 2012 at 6:37
That's fine - why did you move UtcDateTime to legacy code? I guess with the
move to delta serialization the speed benefits associated with structs has been
minimized? Should I return to using a class / DateTime objects?
Original comment by kar...@gmail.com
on 23 Feb 2012 at 6:59
I moved it because UtcDateTime is clearly outside of the scope of data storage
system. As for what to use - in our projects we continue using UtcDateTime,
except that we define it in our own code, together with Date and other similar
objects that can be used for indexing. I don't know if structs or classes will
be more efficient - only experiments can tell.
Original comment by yuriastrakhan
on 23 Feb 2012 at 7:34
Original issue reported on code.google.com by
kar...@gmail.com
on 23 Feb 2012 at 6:21Attachments: