<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 7, 2018 at 4:25 AM Tamas Bunth <<a href="mailto:tamas.bunth@collabora.co.uk">tamas.bunth@collabora.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Mon, May 07, 2018 at 03:24:49AM +0000, Drew Jensen wrote:<br>
> Looking at the open issues for the HSQL to Firebird auto migration<br>
> functionality particular the issues regarding data types and other test<br>
> files I put together a possible map of what I think makes sense in<br>
> translating hsql to firebird types.  [Read only view of it here<br>
> <a href="https://nextcloud.documentfoundation.org/s/TTBT4fJ2xTdbMJQ" rel="noreferrer" target="_blank">https://nextcloud.documentfoundation.org/s/TTBT4fJ2xTdbMJQ</a> ]<br>
> <br>
> I'm sharing it here for two purposes, first it would be a big help to have<br>
> this type of thing with whatever the actual mapping is - so - if that is<br>
> already set I could really use for someone to let me know what would need<br>
> to change there.<br>
<br>
- Image type has a special subtype, so it can be distinguished from a normal<br>
  BLOB later: BLOB SUB_TYPE -9546<br>
<br>
- Binary [VARBINARY] is mapped to VARCHAR with a special character set<br>
  "OCTETS".<br>
<br>
- Binary(fix) is mapped to CHAR with character set "OCTETS".<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ok - updated my map and will do the same for wiki page<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The are three suggested changes;<br>
> first is to treat OTHER[OTHER] as a custom subt_type (-1) of blob instead<br>
> of a CLOB as this would give the same behavior in Base with firebird as<br>
> with hsql<br>
<br>
IIRC I didn't implement any mapping from type OTHER. It just skips the column<br>
currently. I skipped it because I couldn't find any test files in Bugzilla for<br>
OTHER column types, so I assumed nobody uses it. :)<br>
<br>
It would make sense to map it to BLOB or to VARCHAR with character set octets<br>
though.<br></blockquote><div><br></div><div>Well, I ran a test file through with a field of type OTHER and what I got was a column of the same name and type of CLOB. I did NOT run any actual data through, just the column however.</div><div><br></div><div>All the single data type tests I ran are found on the tdf nextcloud also. <span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">A link for that is <a href="https://nextcloud.documentfoundation.org/s/W92TGtQpprximdB">https://nextcloud.documentfoundation.org/s/W92TGtQpprximdB</a> (The are in the directory SingleFieldType)</span></div><div><br></div><div>The idea is to end up with a collection of test files that pass through the migration function without error and with expected results. As the simpler tests pass I start adding a bit more (so first it was just column definitions then I added data) and as the project moves from stage to stage (Alpha, Beta, RC, ... Release) I will go back and run the whole batch to ensure no regressions. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> second is to treat HSQL Binary(fix)[BINARY] as Binary[BINARY]  with<br>
> sub_type of 0 or 1 based on a scan of some number of the records checking<br>
> for text data<br>
<br>
I think if the user wanted to store textual data then he would have created a<br>
CHAR / VARCHAR column at the first place.<br>
<br>
Besides that, the user can change the character set from OCTETS to UTF8 later<br>
(with a direct sql). After that the column would act like a normal CHAR/VARCHAR<br>
in the database.<br>
<br>
Thanks,<br>
Tamás<br>
</blockquote></div></div>