I have the following code, where "CI_COL" is of type citext (https://www.postgresql.org/docs/current/static/citext.html)
String str = "testING";
int countBad = context.fetchCount(select(Tables.MY_TABLE.CI_COL)
.from(Tables.MY_TABLE)
.where(Tables.MY_TABLE.CI_COL.eq(str)));
int countGood = context.fetchCount(select(Tables.MY_TABLE.CI_COL)
.from(Tables.MY_TABLE)
.where(Tables.MY_TABLE.CI_COL.eq(cast(str, new DefaultDataType<>(SQLDialect.POSTGRES, String.class, "citext")))));
The first query returns 0, and the second query correctly returns > 0.
It took me a long time to track down the root cause, because when the first query was printed (or found in the DEBUG logging), it seemed to execute in the terminal just fine.
Once I got down to the statement level and actually started binding values, that's where the root cause seemed to be. It seems to be an issue (or on purpose) in the postgres driver. This post illustrates the binding issue with citext: https://www.postgresql.org/message-id/CAJFs0QB90bo0vWw5pZcw0c%3DLjOcOX04qPEM4nSd6uY7-T2r5hA%40mail.gmail.com
Is it possible to fix this at the JOOQ level, by having JOOQ automatically perform a cast on all right hand side values for a specific column?
Side note
new DefaultDataType<>(...)
Ghasp! You're using internal API :)
Correct solution
The correct way to introduce new data types in jOOQ is to use a Converter, or in this case a data type Binding:
http://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-bindings
While most Binding method implementations would simply delegate to jOOQ's DefaultBinding, you can override the sql() method (which generates the bind variable's SQL string) to this:
#Override
public void sql(BindingSQLContext<JsonElement> ctx) throws SQLException {
ctx.render().sql("?::citext");
}
Related
I am using entity framework and I want to execute a query and would like to know which is the besr way to execute a query. Which is best practice and why, and which one is more per-formant.
Option 1)
return
this.Storage.Customer.OfType<Preferred>()
.Include("Order")
.Where("it.Id = #customerId AND it.CustomerType = #cusType", new ObjectParameter("customerId ", customerId), new ObjectParameter("cusType", (int)cusType))
.Execute(MergeOption.OverwriteChanges)
.SingleOrDefault();
OR
return
this.Storage.Customer.OfType<Preferred>()
.Include(b => b.Order)
.Where(cust => cust.Id == customerId && cust.CustomerType== (int)cusType)
.SingleOrDefault();
The second question is why in option 2 us the .Execute not available? It appears red.
Thanks in advance.
The performance difference should be negligible compared with the actual data access, but you need to measure it to determine for sure.
Include with a lambda just uses reflection to get the property name then calls the version with a string parameter, so the only overhead is parsing the expression. (This is an implementation detail, however, so it is subject to change)
The benefit of using a lambda is type safety - using the wrong property name in a lambda will break the build, but using the wrong string will only fail at run-time.
The reason Execute is not available is because Include with a lambda parameter is an extension method on IQueryable<T> that returns an IQueryable<T> in order to chain methods like Where. Include with a string parameter is a method on ObjectQuery<T> that returns an ObjectQuery<T>. Execute is a method on ObjectQuery<T>, not IQueryable<T> so it is not available when you use IQueryable methods.
Is it possible to extend DbFunctions, assuming you are using existing DbFunctions as helper methods. I am essentially rewriting the exact same line of sql code again and again. Are there any alternatives?
Update:
Here is an example of what I'm trying to do, but I want to define my own Add function, not use one that I've constructed in my database
var locations = context.Data.Where(e => Functions.Add(e.X, e.Y) >= 10)
Yes of course you can extend it. Class DbFunctions only contains code that helps the provider of your IQueryable to translate the expression into SQL.
An IEnumerable holds all code to create an Enumerator for you upon request. The Enumerator represents a sequence. Upon request it will give you the first element of the sequence, and once you've got an element it will give you the next one (provided there is one).
An IQueryable works differently. Usually an IQueryable is not meant to be performed by your process, but for instance a database, a remote web site, a CSV file controller, etc.
That is why you need to tell an object that produces IQueryables for which process it must create the IQueryable. In case of Entity Framework you inform the DbContext which database to use.
The IQueryable object holds an Expression to be performed and a Provider. The provider knows which process will perform the query. It also knows how to translate the Expression into the format that the other process understands. Quite often this will be SQL.
If you investigate the remarks section of the MSDN descriptions of IQueryable functions like Where, GroupBy, Select, you'll see that most of these functions will only change the Expression.
As long as you don't ask for the Enumerator, usually implicitly by asking for the first element of a sequence, like in ToList, foreach, FirstOrDefault, etc, the Provider has nothing to do.
But once you ask for the Enumerator, the Expression will be translated by the Provider, who will use the translation to query the data from the other process and create an Enumerator object that can give you the first element of the sequence, and the next ones.
DbFunctions are used when the Provider translates the Expression into SQL. If you create a Queryable with DbFunctions and in your debugger look at the created Expression, you'll still find the used DbFunctions.
The DbFunctions only translate the input into SQL. If does not perform the query itself. The translation is done in local memory.
Having understood this, you can use any function as long as it only changes the Expression into new Expressions into formats that your provider understands.
This means you can't use any of your own functions, or classes. There are even several LINQ functions you can't use
See supported and non-supported LINQ methods
However, if your extension functions input an IQueryable and output an IQueryable, then your extension function will only change the Expression. As long as you fill the Expression with supported LINQ methods you're fine
So if you want to extend IQueryable with a function that returns an IQueryable containing only the invoice that are due to day:
public static IQueryable<Invoice> WhereDueToday(this IQueryable<Invoice> invoices)
{ // returns all invoices that must be paid today
return invoices
.Where(invoice => DbFunctions.TruncateTime(invoice.DueDate) == DateTime.Today);
}
Usage:
IQueryable<Invoice> invoices = dbContext.Invoices
.Where(invoice => ..);
IQueryable<Invoice> invoicesDueToDay = invoices
.WhereDueToday();
You can define a method that returns an Expression and use that in your where clause. Since you want to pass different properties of the object in you can't just write one expressions
public Expression<Func<T, bool>> MyFunc<T>(Expression<T, int> property1, Expression<T, int> property2, int greaterThan)
{
// Build expression tree
}
I realise "Build Expression tree" isn't hugely useful, but if you don't really want to do add writing out the code to build "add" isn't going to help you either.
If there are just a couple of combinations it might be easier to just hard code for those
public Expression<Func<T, bool>> MyFunc<T>(PropertiesEnum p, int greaterThan)
{
switch(p)
{
case (p.XandY):
return item => (item.X + item.Y) > greaterThan;
case (p.XandZ):
return item => (item.X + item.Z) > greaterThan;
case (p.YandZ):
return item => (item.X + item.Z) > greaterThan;
// other cases
}
}
You would call this like:
var locations = context.Data.Where(MyFunc(PropertiesEnum.XandY, 10));
I have a query that I suspect is guilty of parameter-sniffing. I'd like to apply an interceptor like the one found here, but I don't want any other queries affected.
The code used there is: DbInterception.Add(new OptionRecompileHintDbCommandInterceptor());
What is the scope of this command and how do you limit the scope of an interceptor to just a single query?
My first thought was to do something like this:
var interceptor = new OptionRecompileHintDbCommandInterceptor();
try
{
DbInterception.Add(interceptor);
// Do query
}
finally
{
DbInterception.Remove(interceptor);
}
But is this same to do or could it affect queries on other threads?
Update
Another thought occurred to me. If I can't control when an interceptor is applied, is there a way to put the logic in a conditional if statement in the interceptor and then supply some kind of context to the interceptor so it knows when to apply the logic?
Two options I can think of for this, since it is at the global level, is in the query you want to single out, you can do something where you say 9 = 9 or something that is always true so you know it is the query you want. Then you could find and replace that where clause part with an empty string and then continue on with whatever you were going to do.
The other is quite a bit sneakier, but should work. In your interceptor code, you can do this:
var ctx = interceptionContext.DbContexts.FirstOrDefault() As MyDbContext;
But then you should be able to cast it to your specific DbContext type. On that DbContext type, you could just add some boolean property that would indicate this is the query you are running. Then, right before running it, you can set that to true wherever else and you'd be able to intercept it.
I am writing an application which uses ORMLite to connect to a back-end database. Since the application will be run over VPN I am trying to minimize database calls.
In order to minimize database calls I have created a set of classes to wrap the values for each field. Each wrapper class stores the original value returned from the database and also a current value. This allows things like reverting to the original value, or checking whether the value is dirty (ie. only update the database if one or more fields are dirty).
The implication of this regarding ORMLite is that ORMLite never returns a null value when it queries the database (even if the database returns null). If there is a null value in the database it returns a fully initialized "wrapper" with the currentValue and originalValue variables set to null.
It seems that the right place to do this is in a custom persister such as (where StatefulIntegerProperty is the wrapper for the Integer):
public class StatefulIntegerPersister extends BaseDataType {
... misc. other code
#Override
public Object resultToSqlArg(FieldType fieldType, DatabaseResults results, int columnPos) throws SQLException {
Integer result = results.getInt(columnPos);
return new StatefulIntegerProperty((results.wasNull(columnPos)) ? null : result);
}
#Override
public Object sqlArgToJava(FieldType fieldType, Object sqlArg, int columnPos) throws SQLException {
return sqlArg;
}
#Override
public Object javaToSqlArg(FieldType fieldType, Object obj) throws SQLException {
return ((StatefulIntegerProperty)obj).getCurrentValue();
}
#Override
public boolean isStreamType() {
return true; // this is a hack to work around ORMLite setting the value to null in the FieldType.resultToJava function
}
}
I have three questions:
Is this the correct approach?
In the ORMLite FieldType.resultToJava function it seems to do a null check and will replace my wrapper with null if the database returned null. Right now I am getting past this by overriding the isStreamType method in the persister to return true. Is this the best approach, and will I find later an unintended negative side effect?
What is the difference between the resultToSqlArg and sqlArgToJava methods in a custom persister, and specifically, which one of these should I use to wrap the value returned from the DB, and then what should I be doing in the other?
Is this the correct approach?
I don't understand why anything that you are doing here minimizes database calls. Can you start a discussion on the users' mailing list?
Right now you are overriding the resultToSqlArg(...) method when I think you want the sqlArgToJava(...). See below.
Right now I am getting past this by overriding the isStreamType method in the persister to return true. Is this the best approach...
Hrm. If it works then fine but it seems dangerous to use this setting in this manner. If I changed the behavior of the isStreamType() method then this may break your code. At the very least you should have unit tests to confirm this behavior that will break if you upgrade ORMLite.
That said, there is good handling in the code specifically around null values if isStreamType() is true.
What is the difference between the resultToSqlArg and sqlArgToJava...
I've fleshed out the javadocs for these.
resultToSqlArg takes the object from the SQL results and turns it into a java-object suitable to be an argument to SQL commands. For example, if you have a date-long type, this will extract a Long value from the database results.
sqlArgToJava takes the sql-arg value and converts it into our Java field. For example, if you have a date-long type, this will take a Long value and convert it into a Date which matches the entity field.
I think you should override the sqlArgToJava and not the resultToSqlArg.
I'm trying hard to find a solution to be able to override the automapping of my entity.
The flow of execution is that AutoMapping (using conventions) occurs first and then mapping overrides are executed.
My entity "Signature" is already mapped by automapper (do not confuse with Automapper library!) and I want to change the db type of some columns.
If I do something like this:
public class SignatureMap : IAutoMappingOverride<Signature>
{
public void Override(AutoMapping<Signature> mapping)
{
mapping.Map(x => x.SignType).CustomSqlType("character varying");
mapping.Map(x => x.Status).CustomSqlType("integer").Nullable();
}
}
I get NHibernate errors with NpgsqlParameterCollection (index out of range) when trying to execute an insert to the table.
This probably occurs because the mapping.Map function just adds another mapping to the collection instead of overriding one that already exists (I examined the FluentNHibernate source code).
What is the proper way to override the Sql type using IAutoMappingOverride ?
There is nothing wrong with override syntax you use, make sure you:
1) actually reference your overrided mappings in configuration: .UseOverridesFromAssemblyOf<SignatureMap>();
2) verify that NHibernate treat your DB schema as you expect. You may use something like new SchemaExport(config).Create(true, false); for this, this will output sql to console.
If 1 and 2 are ok, than problem might be in your insert code.