Release Note 20140930

Table of Contents

Features & Improvements

This is a summary of the new features and improvements introduced in this release:

Console: Columns Schema Aliasing

We added a new feature that allow assigning user friendly names to columns in the table schema. This relaxes the previously strict column naming format requirement, by which column names had to be limited to lowercase alphanumeric and underscores ‘_’ characters.

Newly imported data whose field / column names don’t obey to this requirement are no longer rejected (and prevented from being added to the table schema) but are allowed to be displayed in the Table’s detail page (also referred to as ‘Table’s tail’ since it contains a sample of the most recent records imported). In order for such columns to be used within a query the Table Setting page automatically creates a column name alias that is SQL friendly and is expected to be used in place of the user friendly name when referring to the column within the query. The user can also customize the ‘SQL Column Alias’ name manually as long as it obeys to the ‘lowercase alphanumeric characters and underscores’ limitation.

Console: Columns Schema Aliasing

APIs: Cloning a Query

After rolling out Saved Queries last week, we added the ability to clone an existing query into a brand new one. This allow users to build a new query starting from the settings of an existing one.

APIs: Cloning a Query

APIs: Manual Query Runs Executing User

Saved Query runs and Scheduled Query manual runs record and display the user that actually trigged the run as opposed to the Query owner and creator.

Presto: Retrying On Query Errors

The Presto worker’s implementation has been improved to handle sporadic errors and retry the queries when the errors are judged temporary.

Presto: Added Support for Aliased Column Names

To support the API change adding support for user friendly column names, Presto was also changed to allow referencing those columns.

Backend: Retrying With Query Result to S3

We implemented a retrying mechanism for Query Result Output to AWS S3. In case of temporary failures while writing the result of a query to AWS S3, the retrying mechanism repeats the write for up to 10 minutes with exponentially increasing wait time between attempts.

Client Libraries: Release Ruby Client v0.8.64

  • Implemented retrying mechanism for GET requests for up to 10 minutes with exponential backoff
  • Similarly added retrying mechanism for POST requests; this is enabled through the initialization option :retry_post_requests.

Toolbelt: Released Ruby CLI v0.11.4

  • Added an option to enable retrying on POST request to take advantage of the Ruby Client Library feature mentioned above
  • Implemented retrying when fetching a job results. Retrying attempts will be made only when the server side HTTP error code is 500 or more or a communication exception occurred

Bug Fixes

These are the most important Bug Fixes made in this release:

Console: /schedules Endpoints For Queries

  • [Problem]
    Users whom have been referring to and documenting their Scheduled Queries using the /schedules/:id endpoints are left with dead links after the endpoint was switched to /queries/:id.
    [Solution]
    Although we had provisioned for the old /schedules/:id endpoint to automatically redirect to the /queries/:id endpoint this was not working as expected.
    Resolved the routing problem on the Frontend side so that accessing a previously created schedule through the /schedules/:id endpoint redirects to the /queries/:id endpoint.

Console: Table Creation Page Doesn’t Redirect to New Table Page On Save

  • [Problem]
    The Table Creation view does not automatically redirect to the newly created table upon pressing save.
    [Solution]
    The table creation logic was not redirecting upon receipt of the successful response to the request of creating the table in the backend.
    A new callback was added to redirect to the newly created table upon receiving the successful response from the backend.

Console: Safari / Webkit Memory Leak

  • [Problem]
    The Console can lead up to 200% CPU utilization when used within the Safari 6 or 7 browsers due to a Webkit memory issue. The problem can occur even when no tab is open within Safari if the Treasure Data Console had been visited recently.
    [Solution]
    This was found to be caused by Safari’s feature called ‘Topsites’. This dashboard is visible by default when there is no tab open and displays a snapshot of the webpage; to maintain the snapshots current, Safari periodically refreshes the website snapshots allowing them to run briefly. In this context, the Console, which is entirely developed with the AngularJS framework, continues to update using Javascript and this can trigger the Webkit memory issue causing the CPU utilization to reach 200%.
    Safari Topsites allow to specify an alternate snapshot view for when a site is docked within the Topsites view: providing this capability for the Console worked around this issue.

Console: New Query From ‘Edit As New Query’ A Job Does Not Redirect

  • [Problem]
    When the user clicks the ‘Edit As New Query’ button from within a Job view, it’s sent to the new query editor where the configuration of the original job had been copied from. The user can than make the modifications it wishes, name the query, and save it. Upon saving the query, the page does not redirect automatically to the newly created Query and does not provide any indication the query was actually successfully saved.
    [Solution]
    This is due to a mishandling of the new query submission when it’s created from a Job and saved as a new Query.
    Modified the logic to redirect to the newly created Query as soon as the form is successfully submitted.

Console: User’s API Key Password Mishandling

  • [Problem]
    If the user’s password contains a URL special character (e.g. ‘#’) the password is sent to the API server truncated. This prevents the user from being able to retrieve its API key.
    [Solution]
    While indeed special URL characters were not properly escaped in building the request URL, this problem is prevalently due to sending the password in a GET request rather than in the body of a POST request.
    Modified the endpoint and Frontend form handling to use a POST request and send the password as part of the POST request’s body, which avoids the problem altogether.

Console: File Uploader Hangs When Parsing Fails

  • [Problem]
    If pre-parsing of the CSV / TSV file fails in the Frontend, the File Uploader never completes.
    [Solution]
    This was found to be due to the file encoding auto-detection logic returning nothing instead of the default ‘utf-8’ file format when the parsing failed.
    The logic was corrected to return file encoding ‘utf-8’ if the encoding auto-detection logic failed.

Last modified: Oct 02 2014 20:25:42 UTC

If this article is incorrect or outdated, or omits critical information, please let us know. For all other issues, please see our support channels.