Redshift tables in Storage API cannot be deleted until its dependencies are removed. Dependencies include any Redshift alias where the source table is involved, or any view in running transformations or sandboxes.
Deleting a table that had some of these dependencies triggered an internal error. This bug is now fixed and dependencies are listed in the error response message.
MySQL storage tables were displaying inaccurate results. Tables loaded by full load often shown zero rows and 32KB size even if the table had many GB.
This bug is now fixed, and these estimates are updated every hour. These values are still not accurate however, as the approximations provided by MySQL are used as the source of these values and they may vary from the actual values by as much as 40 to 50%.
This bug does not affect Redshift storage, row counts and sizes are 100% accurate for Redshift and always have been.
Please review the entire post carefully to determine whether your use of the services will be affected.
As of 12:00 AM PDT April 30, 2015, we will discontinue support of RC4 cipher for securing connections to connection.keboola.com.
Last night(10.4) we've got issues with our transformation server that caused failing of transformations(and so orchestrations), we fixed the issue and restarted all affected orchestrations. Sorry for the inconvenience.
We're announcing few security improvements:
Long story short: if you're connecting to Keboola Connection, client facing servers are covered by strong encryption SSL with displayed identity in browser's address bar + all client's data in Keboola Connection are encrypted by default.
After June 1st 2015 we'll be enforcing strict limits on MySQL queries. All queries longer than 30 minutes (1800 seconds) will be terminated and the transformation will fail. You can now see duration of all queries longer than 2 minutes (120 seconds) in event log of any Transformation job so you can take optimization steps in advance.
We're introducing this limit to prevent errors like forgotten indexes and also to balance load on the shared MySQL Transformation database.
If your queries take significantly longer time than 30 minutes, please consider migrating your project to Redshift.
Our MySQL sandbox server (tapi-ovh.keboola.com) is down. We're firing up another server, will be up shortly.
UPDATE 4.43pm PST: Our backup sandbox server (tapi-sandbox.keboola.com) is up and running.
The Database Extractor now supports Oracle.
We're experiencing very slow connection between our workers and the sandbox DB server. Please bear with us, we'll keep this post updated.
UPDATE 9.30pm PST: Looks like the connectivity is back at full speed. Thanks for your patience.