Re: Saving data with types not available in gnumeric

[Jody Goldberg <jody gnome org>]

On Mon, Jan 23, 2006 at 04:21:51PM +0100, Uwe Steinmann wrote:
> Hi again,
>
> I'm still working on the paradox file save support which is mostly
> ready execpt for a rather general problem concerning cell types
> available in the export format but not in gnumeric. This maybe 
> relevant for other formats as well (e.g. xbase).
> Let me make an example.
> Paradox has 3 different field types to save a date/time.
> One for dates only, one for times only and one for both. gnumeric
> isn't actually aware of time/date at all. It's a just floating point
> number.
> Now, I wonder if there is any way to tell if a certain cell is
> actually a date or time? I suppose there isn't.
There is no absolute way to make the connection.
On load you can use the GnmValue::fmt to set the value's format or
even format the cell.  However, there's nothing in a spreadsheet
that will enforce that connection.

> In that case, I would like to discuss a way to keep the original
> field format in the first line of the sheet, just as alreayd done
> wtth name.
> A 30 character string field with the name 'column1' would e.g.
> result in 'column1,C,30'.
> I'm not sure, but I think this is the way openoffice does it for
> xbase files.
> Any comments.

Seems like we're going to choose between a collection of unpleasant
choices.  Any meaning we assign is going to be weakly coupled and
jeapardized by user changes.  However, I've got a solution in mind
that should give use the tools to do this right.

MS Office 12 has extended their previous kludged Data Table into
something genuinely useful.  The ability to assign semantics to a
range.  They appear to be using it for simple things like styles.
As an example they'll be able to support complex autoformats that
handle col/row ins/del.  If we extend that concept a bit we could
mark the imported data as a 'db-table' and store the associated col
types.

Implementing this is dependent on a few significant archtectural
changes and will hopefully be done some time this summer.  In the
mean time mangled column names sounds no worse than the alternatives
(comments on headers, or magic val formats).