nyurik / timeseriesdb

Automatically exported from code.google.com/p/timeseriesdb
GNU General Public License v3.0
13 stars 6 forks source link

Moving UTCDateTime to Legacy Class caused old files to be unable to find UTCDateTime #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When you moved the UTCDateTime class to the legacy library, it caused files 
built with prior versions to lose track of this class. I added a simple fix to 
FastBinFileUtil to map the full assembly type for UTCDateTime to the legacy 
assembly (see attached).

Original issue reported on code.google.com by kar...@gmail.com on 23 Feb 2012 at 6:21

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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