Re: [mdb-dev] Patches + thoughts

[Brian B. <br...@br...>]

Both applied.

Off the top of my head I don't know a reason we would not escape the
escape character.

The insert code was a patch written by someone else, and I think it
was written in the least obtrusive way (leaving the mainline code
alone and putting it all in export.c), so lacks a certain
cohesiveness.  I'm not faulting the author at all, I should have
reworked the code and integrated it better.

If I read you correctly, you are thinking of having mdb-schema (and
the gui version thereof) generate something like mysqldump or pg_dump
with all schemas, tables, data, keys, etc... in sequence?  I think
it's a good idea.  Next time I'm messing in that area, I'll see what
is to be done.

Brian

2011/2/19 Nirgal Vourgère <con...@ni...>:
> On Friday 18 February 2011 19:38:19 Brian Bruns wrote:
>> I'd like to keep quote/escape (particularly quote, I can't think of a
>> case where escape is more than one char) as a string since it allows a
>> multicharacter delimiter, not as uncommon a convention as you might
>> think.
>
> Right.
> Attached is a revised version of export patch.
>
> That does not really anwser my question: "Should we escape the escape character ?"
> My patch does.
> If you or anyone don't like it, there is a #define DONT_ESCAPE_ESCAPE
>
> Attached is an update for Binary type (should not be treated as Memo).
>
>> I agree that the escaping needs some work as it is often not as simple
>> as adding a simple leading character, but that gets a little
>> complicated and we'd have to bake in some escaping styles rather than
>> the generic switch we now have.
>
> I agree.
>
> But I bet the INSERT version of mdb-export doesn't support charcters < 32 right now, nor non-utf8 characters above 127 (OLE).
>
> I guess the best solution would be to move the INSERT code into the schema exportation tools (backend.c).
> The insert would then occur before foreign keys setup. We could also set up the sequences (autonum/serial) automatically then. And have a full mdb->sql conversion tool with both schema and data.
>
> I don't really have the time for that. Would that be a good idea?
>
>> On unicode2ascii, I have no clue how string compression would work for
>> BIG5, but otherwise it basically punts on the overrun question, it's
>> up to the calling function to properly allocate the size which is
>> generally MDB_BIND_SIZE, which is 4 times the page size, so that
>> should accommodate any code set.
>
> I hit some surprised with props, because I was careless of the unciode conversion expanding size problem at first. I mean column name sizes.
> Anyways. I was thinking about Memo fields. I though the limit was 16k, so that mdbtools might fail after utf-8 conversion.
> But Memo field limit actually is 64k chars (192k bytes in utf-8), so we are in trouble anyways.
>
> Maybe all LVal should be handled the same way, with no automatic binding. We now have 3 versions of lval reading in data.c...
>
> Here's another hint: The table/column props internally have:
> - Name
> - type (like col_type)
> - Buffer (pointer + size)
> Right now, we are converting everything to a proper string, meaning we loose the type. We might want a kind of MdbVariant (type+buffer) that could be played with. Like numeric/date operations.
>
> I have the feeling a MdbVariant might be usefull for binding too. We could probably wrap a LVal reader in it.
>
> Ok, I stop daydreaming now... :)
>