Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
M
massive-js
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 2
    • Merge requests 2
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Dian Fay
  • massive-js
  • Issues
  • #26

Closed
Open
Created Mar 05, 2015 by Dian Fay@dmfayMaintainer

Inconsistent double quote escaping

Created by: Sharkwald

When using CamelCased DB object names, there are a number of instances where the SQL generated is not double quote escaped, causing errors to be thrown.

For example, using Chinook:

db > db.Artist.findOne(1, function(err, result) { console.log(err); });
undefined
db > { [error: relation "artist" does not exist]

Places where I've found this issue so far are the table name, the columns and the default order by (i.e. the pk).

I'm not sure whether to include the custom order by, since it's a supplied string, so the delimiting could be placed in the calling code. On the one hand that feels like a potential gotcha, on the other hand, the whole point is to take advantage of postgres' sql engine, which means playing by its rules.

I think I should have a fix for this ready for a PR soon, but I want to ensure it's properly tested first.

PS: This is the first time I've raised an issue & worked on the fix, so please be gentle!

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking