On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 25-9-2012 10:11, michael.vancann...@wisa.be wrote:
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 18:43, Michael Van Canneyt wrote:
On Mon, 24 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 17:22,
michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org
wrote:
On Mon, 24 Sep 2012, Reinier Olislagers wrote:
Finally, I'll post on the forum that sdf compatibility is not one of
the
goals of sdfdataset.
Is there some defined on-disk format that sdfdataset should be
following?
As I understood it, it is either fixed length or CSV. CSV as in
http://tools.ietf.org/html/rfc4180
People can only go by what they see (they can't read your mind when you
committed sdfdataset).
<snip>
All of this makes it in my opinion more likely to be SDF than CSV.
Like I said, I had never heard of SDF.
I understand (and appreciate) your reasoning when you committed it.
Having a CSV dataset is very handy.
Before I understood the full horror of what SDF really means, especially
as implemented by Delphi (see the nasty behaviour when you add spaces
after a quoted text and before a delimiter) I thought SDF was really
some form of CSV, too. (Well I suppose it is, it's just not RFC4180 CSV
unless you e.g. decide to quote everything. IIRC then it actually
complies with RFC4180).
Look, for me, this is not a requirement set in stone, I am quite flexible.
So am I... see below.
You guys asked what the original idea was, and I explained some of the
history behind the dataset.
Not really, I asked what the specs were ;)
If the desire is to have a TSDFDataset (whatever the specs) and a separate
CSV dataset, fine, we'll make it so, this is really not a problem.
Actually, if you are happy with an SDFDataset that complies with RFC4180
CSV (but not SDF), I would vastly prefer that over the atrocity that is
SDF - as long as this requirement/behaviour is quite clearly specified
(e.g. in a readme).
No problem :-)
If you think that any changes to sdfdataset to make it RFC4180 compliant
are acceptable to current users, fine by me ;)
I have not seen any evidence that it has ever been used other than for CSV,
but I may be wrong. So I suspect that this should be acceptable.
The csvdocument [1] code has a very nice record-by-record CSV parser and
writer with test set that aims to be RFC4180; this could be used for
interoperability testing or even, if evidence by test set failures, used
instead of parts of the current code.
I'm fine with that.
I don't want anyone to feel that he has wasted his time :-)
Well, getting clarity about what the on disk format must be is worth it
even though I can't really say I enjoyed this particular episode :)
Even better, as I said, if everybody is happy with RFC4180 CSV, I vastly
prefer that format to SDF and would consider my time well spent.
I'm sure tatamata from the forum will appreciate it too (AFAIR, his
ZMSQL is based on sdfdataset).
I'm just not interested right now in implementing either a test set or
the changes myself, but perhaps somebody else is.
Well, in the not-too-far future, I'll spend time on improving the DB testsuite.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
