Skip to content

Table map and error event improvements #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: error_handling
Choose a base branch
from

Conversation

jmealo
Copy link
Contributor

@jmealo jmealo commented Nov 18, 2015

Improvements:

  1. ctrlConnection errors and unhandledErrors will be relayed by Zongji
  2. The table map now includes constraints (null or object) and nullable (boolean) properties.

For discussion

  1. I'd like to store the type rather than the code. Will this break anything internally?

Given the following DDL:

CREATE TABLE `example_table` (
  `ID` int(11) DEFAULT NULL,
  `student_id` int(11) NOT NULL DEFAULT '0',
  `section_id` int(11) NOT NULL DEFAULT '0',
  `teacher_id` int(11) NOT NULL DEFAULT '0',
  `resource_id` int(11) NOT NULL DEFAULT '0',
  `comment` text,
  `rating` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`section_id`,`student_id`,`resource_id`,`teacher_id`),
  UNIQUE KEY `ID` (`ID`)
);

Your table map columns would look like this:

[
  {
    "name": "ID",
    "charset": null,
    "type": 3,
    "nullable": true,
    "constraint": {
      "type": "UNIQUE",
      "position": 1,
      "name": "ID"
    }
  },
  {
    "name": "student_id",
    "charset": null,
    "type": 3,
    "nullable": false,
    "constraint": {
      "type": "PRIMARY KEY",
      "position": 2,
      "name": "PRIMARY"
    }
  },
  {
    "name": "section_id",
    "charset": null,
    "type": 3,
    "nullable": false,
    "constraint": {
      "type": "PRIMARY KEY",
      "position": 1,
      "name": "PRIMARY"
    }
  },
  {
    "name": "teacher_id",
    "charset": null,
    "type": 3,
    "nullable": false,
    "constraint": {
      "type": "PRIMARY KEY",
      "position": 4,
      "name": "PRIMARY"
    }
  },
  {
    "name": "resource_id",
    "charset": null,
    "type": 3,
    "nullable": false,
    "constraint": {
      "type": "PRIMARY KEY",
      "position": 3,
      "name": "PRIMARY"
    }
  },
  {
    "name": "comment",
    "charset": "utf8",
    "type": 252,
    "nullable": true,
    "metadata": {
      "length_size": 2
    }
  },
  {
    "name": "rating",
    "charset": null,
    "type": 1,
    "nullable": true
  }
]         

' AND t.CONSTRAINT_NAME = k.CONSTRAINT_NAME',
' WHERE c.TABLE_SCHEMA = "%s"',
' AND c.TABLE_NAME = "%s"'
].join(' ').replace(/\s{2,}/g, ' ');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how a DBA taught me to format SQL for readability, it's opinionated so I'm fine with just truncating it at 80 characters onto however many lines if that makes everyone happy.

It seemed like a good idea to get rid of the extra spaces once rather than sending them over with every query. If the join bothers anyone it can be converted to a string, it's only going to run once so performance shouldn't be a concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant