I'll should be able to create RC2 at the weekend or sooner.
Gary
On Tue, Jan 28, 2020 at 10:28 AM Alex Herbert <alex.d.herb...@gmail.com>
wrote:
>
> On 28/01/2020 15:15, Gary Gregory wrote:
> > On Mon, Jan 27, 2020 at 7:58 PM Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >
> >> 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.
> >>
> > Thanks for the update Alex. Do we want anything else for RC2?
>
> Not from me. Serialization is fixed (for compatibility) and the docs now
> state it won't be fully functional going forward. I hope that is the end
> of that.
>
> > Gary
> >
> >
> >> 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
> >>>>>>>
> >>>>>>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
