Issues/Quirks with Oracle SQL*Loader integration # The Problem I'm having some trouble around using the Oracle SQL*Loader backed bulk_insert in sling. I'm in a Windows environment. I'm loading .txt files into an Oracle database, the file has no headers so I define them in my repl.yaml. Otherwise I've explicitly set use_bulk to true and set some filey things like delimiter. Sling successfully pulls the file into a .csv and that looks all good. The issue is the ctl file for SQL*Loader defines every column as char(400000). This persists when I attempt to use target_option: column_typing to set a max length for strings or when I explicitly set datatypes to string(250). When SQL*Loader then goes to run this ctl file, it seems to attempt to pre-allocate memory for each column - there's 122 in this load which means, at that char() def, about 45MB per row. It only takes around 600 rows at that rate to blow out my 32GB of RAM, and the process fails. Doing this on a less wide table works successfully but only because I don't run out of ram. About 40KB of csv file briefly consumes 2.5GB memory # The Questions It appears that sling is failing to automatically infer the length of my datatypes then defaulting to it's max size of char(400,000), is that correct? Is there any common mistakes on my side that could be causing this, or is it intended behaviour and SQL*Loader on Windows is just a nightmare? A similar job I have loads from a sqlserver source. It still appears to have the massive char() in the ctl file but the resultant table is normally typed - is this something that sling does when moving from tmp table to final one? Any other thoughts/advice welcome - thanks!

Thank youfor reporting @Daniel , was able to reproduce this. This is a bug for the

column_typing.string

. Fixed for next release!