On Mon, Jan 27, 2020 at 6:54 PM Alex Herbert <alex.d.herb...@gmail.com>
wrote:
> I’ve had a look at the Serialization of CSVRecord. Fields have been added
> and removed from CSVRecord as:
>
> 1.0
>
> /** The accumulated comments (if any) */
> private final String comment;
>
> /** The column name to index mapping. */
> private final Map<String, Integer> mapping;
>
> /** The record number. */
> private final long recordNumber;
>
> /** The values of the record */
> private final String[] values;
>
> 1.1
>
> // Added
>
> private final long characterPosition;
>
> 1.2 to 1.6
>
> No changes
>
> 1.7
>
> // Removed
>
> /** The column name to index mapping. */
> private final Map<String, Integer> mapping;
>
> // Added a non-serialisable field -> broken
>
> /** The parser that originates this record. */
> private final CSVParser parser;
>
> 1.8
>
> // Fixed by marking as transient
> private final transient CSVParser parser;
>
>
> If you write and read records in 1.8 the parser is not serialised. This
> contains the map between column names and indices. So the following methods
> are affected:
>
> boolean CSVRecord.isMapped(String);
> boolean CSVRecord.isSet(String);
> Map<String, String> CSVRecord.toMap();
> String CSVRecord.get(String);
>
> The original object would have valid returns for these. A deserialised
> version returns false for all map keys, the map representation is an empty
> map and get will throw as access by name is not supported.
>
>
> You can read records from 1.0 in using 1.8. It ignores the map that was
> serialised as part of the record. It also ignore the missing character
> position field and assigns it a default value of 0.
>
>
> Likewise you can read records from 1.8 in using 1.0. Here the map is
> missing and so all functionality linked to the map fails. The failures are
> exactly as for reading 1.0 in to 1.8.
>
>
> So this indicates you can serialise and deserialise between different
> versions back to 1.0 excluding 1.7. Deserialisation may not create records
> entirely. The following lists what should work with no loss of
> functionality in the destination version:
>
> Serialised from => deserialised to
>
> 1.0 => 1.0
> 1.1 - 1.6 => 1.0 (the character position field is ignored)
> 1.1 - 1.6 => 1.1 - 1.6
>
> The following will result in absent information:
>
> 1.0 => 1.1 - 1.6 (no character position)
> 1.0 => 1.8 (no character position, no mapping functionality)
> 1.1 - 1.6 => 1.8 (no mapping functionality)
> 1.8 => 1.0 - 1.8 (no mapping functionality)
>
> 1.7 is ignored as it cannot be serialised
>
>
> So even though you can deserialise between versions without an exception
> the functionality is impaired in certain cases, i.e. when jumping between
> 1.0-1.6 and 1.8. Since deserialisation can create an instance a change to
> the serial version ID is not warranted. The compatibility should be noted
> in the documentation, e.g. something like:
>
> * <p>
> * Note: Support for {@link Serializable} is scheduled to be removed in
> version 2.0.
> * In version 1.8 the mapping between the column header and the column
> index was
> * removed from the serialised state. The class maintains serialization
> compatibility
> * with versions pre-1.8 for the record values; these must be accessed by
> index
> * following deserialization. There will be loss of any functionally
> linked to the header
> * map when transferring serialised forms pre-1.8 to 1.8 and vice versa.
> * </p>
>
> Thoughts on this?
>
+1 to updating the docs.
Gary
>
> Alex
>
> > On 25 Jan 2020, at 23:02, Alex Herbert <alex.d.herb...@gmail.com> wrote:
> >
> >
> >
> >> On 25 Jan 2020, at 22:05, Gary Gregory <garydgreg...@gmail.com> wrote:
> >>
> >> Hi Alex,
> >>
> >> Is there more you'd like to do for 1.8?
> >>
> >
> > Not functionality. The remaining things are the documentation of:
> >
> > - the intent to remove Serialisation support to the CSVRecord in 2.0
> > - the intent to not support Serialisation of additional fields added
> after from 1.6
> >
> > This is for the CSVRecord class header and to the release notes in
> changes.xml.
> >
> > We have the test to show that you can deserialise from 1.6. I think that
> I should change the .bin serialised file to the version from 1.0. Thus the
> test demonstrates serialisation compatibility with the original version.
> Adding 1.1 through 1.6 could be done although I do not see the need. No
> fields were added until 1.7.
> >
> > WDYT?
> >
> >
> >> Gary
> >>
> >>
> >> On Fri, Jan 24, 2020 at 12:36 PM Gary Gregory <garydgreg...@gmail.com>
> >> wrote:
> >>
> >>> On Fri, Jan 24, 2020 at 11:09 AM sebb <seb...@gmail.com> wrote:
> >>>
> >>>> On Fri, 24 Jan 2020 at 15:05, Alex Herbert <alex.d.herb...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On 24/01/2020 13:34, Gary Gregory wrote:
> >>>>>> On Fri, Jan 24, 2020 at 6:14 AM sebb <seb...@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Thu, 23 Jan 2020 at 18:10, Alex Herbert <
> alex.d.herb...@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 23/01/2020 13:55, sebb wrote:
> >>>>>>>>> I think we don't want temporary serialisation fixes to encourage
> >>>> the
> >>>>>>>>> use of serialisation.
> >>>>>>>>>
> >>>>>>>>> So I suggest that the Release Notes and Javadoc should point out
> >>>> that
> >>>>>>>>> although serialisation is possible, it is not fully supported,
> and
> >>>>>>>>> that there are plans to drop all serialisation support.
> >>>>>>>> The javadoc for the new field that is not serialized have been
> >>>>>>>> documented. This current code is able to deserialize a record
> >>>> created
> >>>>>>>> using version 1.0 and 1.6. I did not test the in between releases.
> >>>>>>>> Serialisation broke in 1.7.
> >>>>>>>>
> >>>>>>>> Should a note be added to the header for CSVRecord stating that
> the
> >>>>>>>> class is serialization compatible with version 1.0 - 1.6. Fields
> >>>> added
> >>>>>>>> after version 1.6 are not serialized and the intension is to
> remove
> >>>>>>>> serialisation support in version 2.0.
> >>>>>>>>
> >>>>>>>> WDYT?
> >>>>>>> LGTM (apart from some spelling issues!)
> >>>>>>>
> >>>>>>> However, I think it's worth noting in the Release Notes as well.
> >>>>>>>
> >>>>>> I'm OK with what Sebb said.
> >>>>>>
> >>>>>> Gary
> >>>>>
> >>>>> OK. I'll update the description in the changes.xml for this release
> >>>>> (which IIUC become the release notes)
> >>>>
> >>>> This is not automatic, but yes, changes.xml can be used to generate
> the RN
> >>>>
> >>>
> >>> I use the changes.xml file to generate the RNs.
> >>>
> >>> Gary
> >>>
> >>>
> >>>>
> >>>>> and javadoc the CSVRecord in the
> >>>>> class header.
> >>>>
> >>>> Thanks!
> >>>>
> >>>>> Alex
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Alex
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>
> >>>>
> >
>
>
