I am looking to cleanly implement a mechanism to override all where clauses that compare strings to do the following
[Column].Value.ToLower() == SqlParam.ToLower()
effectively overcoming the case sensitivity of Postgres.
OrmLite's INamingStrategy allows you to customize how Schemas, Tables and Columns are named and OrmLite's PostgreSQL Provider is already configured to use the PostgreSqlNamingStrategy which converts or .NET's PascalCase names to PostgreSQL-friendly snake_case.
Related
So I'm new to SQL like databases and the place that I work at migrated to PostgreSQL. One table drastically reduced its contents. The point is, I only used SELECT statements, and changed the name of the columns with AS. Is there a way I might have changed the table data?
When you migrate from a DBMS to another DBMS you must be sure that the objects created are strictly equivalent... The question seems to be trivial, but is'nt.
As a matter fact one important consideration for litterals (char/varchar...) is to verify the collation used formerly and the collation you have used to create the newly database in PostGreSQL.
Collation in an RDBMS is the way to adjust the behavior of character strings with regard to certain parameters such as the distinction, or not, of upper and lower case letters, the distinction, or not, of diacritical characters (accents, ligatures...), specific sorting to language, etc. And constitutes a superset of the character encoding.
Did you verify this point when using some WHERE clause to search some litterals ? If not, try to restricts litteral in applying the right collation (COLLATE operator) or use UPPER function to avoid the distinguish between upper and lower chars...
I have a basic REST service backed by a PostgreSQL database with a table with various columns, one of which is a JSONB column that contains arbitrary data. Clients can store data filling in the fixed columns and provide any JSON as opaque data that is stored in the JSONB column.
I want to allow the client to query the database with constraints on both the fixed columns and the JSONB. It is easy to translate some query parameters like ?field=value and convert that into a parameterized SQL query for the fixed columns, but I want to add an arbitrary JSONB query to the SQL as well.
This JSONB query string could contain SQL injection, how can I prevent this? I think that because the structure of the JSONB data is arbitrary I can't use a parameterized query for this purpose. All the documentation I can find suggests I use parameterized queries, and I can't find any useful information on how to actually sanitize the query string itself, which seems like my only option.
For example a similar question is:
How to prevent SQL Injection in PostgreSQL JSON/JSONB field?
But I can't apply the same solution as I don't know the structure of the JSONB or the query, I can't assume the client wants to query a particular path using a particular operator, the entire JSONB query needs to be freely provided by the client.
I'm using golang, in case there are any existing libraries or code fragments that I can use.
edit: some example queries on the JSONB that the client might do:
(content->>'company') is NULL
(content->>'income')::numeric>80000
content->'company'->>'name'='EA' AND (content->>'income')::numeric>80000
content->'assets'#>'[{"kind":"car"}]'
(content->>'DOB')::TIMESTAMP<'2000-01-30T10:12:18.120Z'::TIMESTAMP
EXISTS (SELECT FROM jsonb_array_elements(content->'assets') asset WHERE (asset->>'value')::numeric > 100000)
Note that these don't cover all possible types of queries. Ideally I want any query that PostgreSQL supports on the JSONB data to be allowed. I just want to check the query to ensure it doesn't contain sql injection. For example, a simplistic and probably inadequate solution would be to not allow any ";" in the query string.
You could allow the users to specify a path within the JSON document, and then parameterize that path within a call to a function like json_extract_path_text. That is, the WHERE clause would look like:
WHERE json_extract_path_text(data, $1) = $2
The path argument is just a string, easily parameterized, which describes the keys to traverse down to the given value, e.g. 'foo.bars[0].name'. The right-hand side of the clause would be parameterized along the same rules as you're using for fixed column filtering.
i am working with PostgreSQL database. I have my all tables following camel case naming convention for columns. How to use same structure with PostgreSQL>
All identifiers (including column names) that are not double-quoted are folded to lower case in PostgreSQL.
Column names that were created with double-quotes and thereby retained upper-case letters (and/or other syntax violations) have to be double-quoted for the rest of their life.
So, in PostgreSQL column names are case-sensitive depending on the way they are created.
I recommend you to create column names in lower case so that you can query them the way you prefer.
I want to create a table in Amazon Redshift with PascalCase notation. How do I achieve this?
E.g.: I want the table name to be "EmployeeDetails" and not as default way in which it gets created as "employeedetails".
Identifiers and names in Redshift are case-insensitive.
Standard and delimited identifiers are case-insensitive and are folded
to lower case. Identifiers must consist of only UTF-8 printable
characters.
Source
I recommend using snake_case, as #a_horse_with_no_name suggested. This is the standard way of doing it.
I've seen that DBMS like MySQL supports query containing regular expressions. Does Eclipselink support this?
I have to retrieve entities having some String attribute matching some regular expression as
SELECT X FROM Person X WHERE X.name <some keyword> (A-Z)*
MySQL uses REGEX or RLIKE for regular expression queries. JPQL does not support these operators, so you can use a native SQL query.
In EclipseLink you could define your own ExpressionOperator for these, and use it in an Expression query, but not currently with JPQL. JPQL does support calling database functions using FUNC, but these have different syntax than functions. You could extend the MySQLPlatform to make #like us REGEX or RLIKE.
Please log a bug for this on EclipseLink. Most databases now support regex, so this support should be available in JPQL.