I am trying to take advantage of Exposed's type-safe DSL on top of Vert.x SQL Client to have both type-safety and throughput. I know currently Exposed doesn't support any reactive/async/non-blocking database clients yet (see #456, #732, etc.), but a simple workaround is to generate SQLs for them.
Q: How to get a plain SQL query which will be executed? provides a solution using fun prepareSQL(builder: QueryBuilder): String for Querys, and for DeleteStatements, InsertStatements, and UpdateStatments, etc., I can use fun prepareSQL(transaction: Transaction): String and adapt the original library code a little bit to make it generate both plain SQLs and prepared SQLs. However, when I execute the code directly I get the following exception:
Exception in thread "main" java.lang.IllegalStateException: Please call Database.connect() before using this code
Since I don't use Exposed's API but use Vert.x SQL Client's to connect to the database, calling Database.connect and transaction would mean a waste of resources. So how do I do this without calling Database.connect or having a Transaction? I couldn't figure this out myself since it seems Exposed is too tightly coupled with JDBC and a lot of code's visibility is quite restricted. For example, I also tried creating a dummy no-op Database but couldn't succeed because it has a private constructor.
In addition, can I also generate SQLs using the DAO API?
Related
A common way to interact with a SQL database in Go is to use the built in database/sql interface. Many different third-party packages implement this interface in a way that is specific to some particular database without exposing that work to you as a consumer, e.g. Postgres driver, MySQL driver, etc.
However, database/sql doesn't provide any specific error types, leaving it up to the driver instead. This presents a problem: any error handling you do for these specific errors beyond nil checks now works off of the assumption of a particular driver. If you decide to change drivers later, all of the error handling code must be modified. If you want to support multiple drivers, you need to write additional checks for that driver too.
This seemingly undermines the primary benefit of using interfaces: portability with an agreed-upon contract.
Here's an example to illustrate this problem using the jackc/pgx/v4/stdlib driver and suite of helper packages:
import (
"database/sql"
"errors"
"github.com/jackc/pgconn"
"github.com/jackc/pgerrcode"
)
// Omitted code for the sake of simplification, err comes from database/sql
if err != nil {
var pgerr *pgconn.PgError
if errors.As(err, &pgerr) {
if pgerrcode.IsIntegrityConstraintViolation(pgerr.SQLState()) {
return nil, errors.New("related entity does not exist")
}
}
// If we wanted to support another database driver, we'd have to include that here
return nil, errors.New("failed to insert the thing")
}
If I already have to put driver-specific code into my package, why bother accepting the database/sql interface at all? I could instead require the specific driver, which is arguably safer since it prevents the consumer from trying to use some other unsupported driver that we don't have error handling for.
Is there better way to handle specific database/sql errors?
You don't need driver specific code to get SQLState. Example:
func getSQLState(err error) {
type checker interface {
SQLState() string
}
pe := err.(checker)
log.Println("SQLState:", pe.SQLState())
}
But SQLState is a database specific anyway. If you switch to another database/driver in the future then you need to change all error codes manually. Compiler would not help to detect it.
Package sql provides a generic interface around SQL (or SQL-like) databases.
There is a compromise between providing the minimal common set of features, and providing features that would not be available for all implementations. The sql package has prioritized the former, while maybe you prefer more of the latter.
You could argue that every possible implementation should be able to provide a specific error for your example. Maybe that's the case. Maybe not. I don't know.
Either way it is possible for you to wrap pgerrcode.IsIntegrityConstraintViolation inside a function that does this check for every driver that you support. Then it is up to you to decide how to deal with drivers that lacks support.
I am writing an interpreter implemented functionally using a variations of the Cont Monad. Inspired by Smalltalk's use of images to capture a running program, I am investigating how to serialize the executing hosted program and need help determining how to accomplish this at a high level.
Problem Statement
Using the Cont monad, I can capture the current continuation of a running program in my interpreter. Storing the current continuation allows resuming interpreter execution by calling the continuation. I would like to serialize this continuation so that the state of a running program can be saved to disk or loaded by another interpreter instance. However, my language (I am both targeting and working in Javascript) does not support serializing functions this way.
I would be interested in an approach that can be used to build up the continuation at a given point of execution given some metadata without running the entire program again until it reaches that point. Preferably, minimal changes to the implementation of the interpreter itself would be made.
Considered Approach
One approach that may work is to push all control flow logic into the program state. For example, I currently express a C style for loop using the host language's recursion for the looping behavior:
var forLoop = function(init, test, update, body) {
var iter = function() {
// When test is true, evaluate the loop body and start iter again
// otherwise, evaluate an empty statement and finish
return branch(test,
next(
next(body, update),
iter()),
empty);
};
return next(
init,
iter());
};
This is a nice solution but if I pause the program midway though a for loop, I don't know how I can serialize the continuation that has been built up.
I know I can serialize a transformed program using jumps however, and the for loop can be constructed from jump operations. A first pass of my interpreter would generate blocks of code and save these in the program state. These blocks would capture some action in the hosted language and potentially execute other blocks. The preprocessed program would look something like this:
Label Actions (Block of code, there is no sequencing)
-----------------------------------
start: init, GOTO loop
loop: IF test GOTO loop_body ELSE GOTO end
loop_body: body, GOTO update
update: update, GOTO loop
end: ...
This makes each block of code independent, only relying on values stored in the program state.
To serialize, I would save off the current label name and the state when it was entered. Deserialization would preprocess the input code to build the labels again and then resume at the given label with the given state. But now I have to think in terms of these blocks when implementing my interpreter. Even using composition to hide some of this seems kind of ugly.
Question
Are there any good existing approaches for addressing this problem? Am I thinking about serializing a program the entirely wrong way? Is this even possible for structures like this?
After more research, I have some thoughts on how I would do this. However, I'm not sure that adding serialization is something I want to do at this point as it would effect the rest of the implementation so much.
I'm not satisfied with this approach and would greatly like to hear any alternatives.
Problem
As I noted, transforming the program into a list of statements makes serialization easier. The entire program can be transformed into something like assembly language, but I wanted to avoid this.
Keeping a concept of expressions, what I didn't originally consider is that function calls can occur inside of deeply nested expressions. Take this program for example:
function id(x) { return x; }
10 + id(id(5)) * id(3);
The serializer should be able to serialize the program at any statement, but the statement could potentially be evaluated inside of an expression.
Host Functions In the State
The reason the program state cannot be easily serialized is that it contains host functions for continuations. These continuations must be transformed into data structures that can be serialized and independently reconstructed into the action the original continuation represented. Defunctionalization is most often used to express a higher order language in a first order language, but I believe it would also enable serialization.
Not all continuations can be easily defunctionalized without drastically rewriting the interpreter. As we are only interested in serialization at specific points, serialization at these points requires the entire continuation stack be defunctionalized. So all statements and expressions must be defunctionalized, but internal logic can remain unchanged in most cases because we don't want to allow serialization partway though an internal operation.
However, to my knowledge, defunctionalization does not work the Cont Monad because of bind statements. The lack of a good abstraction makes it difficult to work with.
Thoughts on a Solution
The goal is to create an object made up of only simple data structures that can be used to reconstruct the entire program state.
First, to minimize the amount of work required, I would rewrite the statements level interpreter to use something more like a state machine that can be more easily serialized. Then, I would defunctionalize expressions. Function calls would push the defunctionlized continuation for the remaining expression onto an internal stack for the state machine.
Making Program State a Serializable Object
Looking at how statements work, I'm not convinced that the Cont Monad is the best approach for chaining statements together (I do think it works pretty well at the expression level and for internal operations however). A state machine seems more natural approach, and this would also be easier to serialize.
A machine that steps between statements would be written. All other structures in the state would also be made serializable. Builtin functions would have to use serializable handles to identify them so that no functions are in the state.
Handling Expressions
Expressions would be rewritten to pass defunctionalized continuations instead of host function continuations. When a function call is encountered in an expression, it captures the defunctionalized current continuation and pushes it onto the statement machine's internal stack (This would only happen for hosted functions, not builtin ones), creating a restore point where computation can resume.
When the function returns, the defunctionalized continuation is passed the result.
Concerns
Javascript also allows hosted functions to be evaluated inside almost any expression (getters, setters, type conversion, higher order builtins) and this may complicate things if we allow serialization inside of those functions.
Defunctionalization seems to require working directly with continuations and would make the entire interpreter less flexible.
I have a dll that hides differences of different ADO.NET providers and has lots of code like:
private static void AppendProviderSpecificParameterCmdStr(StringBuilder sb, DbCommand cmd, string fieldNameToUse, ComparisonOperator oprtr, string parameterName)
{
if (cmd is System.Data.OracleClient.OracleCommand || cmd is Oracle.DataAccess.Client.OracleCommand)
{
sb.AppendFormat("{0}{1}:{2}", fieldNameToUse, GetComparisonOperatorStr(oprtr, cmd), parameterName);
}
else if (cmd is SqlCommand)
{
sb.AppendFormat("{0}{1}#{2}", fieldNameToUse, GetComparisonOperatorStr(oprtr, cmd), parameterName);
}
else if (cmd is OleDbCommand)
{
sb.AppendFormat("{0}{1}?", fieldNameToUse, GetComparisonOperatorStr(oprtr, cmd));
}
else
{
throw new Exception(string.Format("Wrong database command type: {0},", cmd.GetType()));
}
}
where Comparison operator is my own enum.
Oracle.DataAccess is present on all machines that have oracle client and this code have been ok for my needs. However now I've faced a situation where there is only SqlClient and they have no need to have oracle at all. So my code works only if I copy Oracle.DataAccess.dll which is naturally a horrible solution. How this should be done the correct way?
Thanks -matti
I wouldn't call a dependency on dll a horrible solution. Your solution supports Oracle and consequently you have an oracle dll in your solution - it is what it is.
That said, there are things you could do abstract away the command type.
One - create complete data access methods that implement an interface. Your current solution I'd classify as more of a helper or utility method for generic data access. You could instead declare an interface specific instead to a domain - customer for example - like ICustomerDA. In your case you'd have 3 implementations of ICustomerDA.Insert, with the database specifics buried inside. Your main code would only need to know about ICustomerDA. This is probably what I would do in a larger solution as differences and features between RDBMSs go well beyond parameter declaration.
Two - If you wanted to stick with more of the helper/utility idea, you could create an interface for a wrapper for db objects, say IDBCommand. Implementations IDBCommand would hide the underlying command object, and then have specific implementations of an .AppendProviderSpecificParameterCmdStr method which would allow you to do something like:
OracleDbHelper : IDbCommand...
public void AppendProviderSpecificParameterCmdStr(...){
sb.AppendFormat("{0}{1}:{2}", fieldNameToUse, GetComparisonOperatorStr(oprtr, cmd), parameterName);
}
IDBCommand cmd = DAFactory.GetCommand();
cmd.AppendProviderSpecificParameterCmdStr(...
The key to both of these solutions is referencing by a common interface from your main project rather than individual types. Once you did this, you could use reflection in your factory or better yet, something like MEF to create the actual types.
So my code works only if I copy Oracle.DataAccess.dll
Not unless you also have the native OCI DLLs, for example because you have already installed the Oracle Client.
To avoid forcing your users to install the full Oracle Client, you can distribute the DLLs from the Oracle Instant Client together with the application. If user never chooses to connect to Oracle, these DLLs are never called and just sit there quietly without causing any trouble.
For some hints on what to distribute and how to cover both 32-bit and 64-bit, take a look at this post.
We have a home-grown abstraction layer that currently works with Oracle and MS SQL Server (and is portable to any DBMS with a decent ADO.NET provider), and this system has worked quite well so far.
We are finding issues (and reporting them) in EclipseLink's InformixPlatform class--the class responsible for adapting the Informix database to the requirements of the EclipseLink innards.
We have a couple of type conversion issues. For example, Informix supports two opaque literals (t and f--not the characters, but actual literals) as native boolean values. It appears that perhaps EclipseLink is trying to use SMALLINT instead as the database type.
Short of a lot of procedural code inside a SessionCustomizer, I cannot find a good place to correct or improve such global conversion behavior.
Where is the best place to register this global take-a-value-from-the-database-and-convert-it-to-a-Java-object behavior? Other questions seem to indicate that this is impossible, but I find that very hard to believe.
Build your own conversion manager class (extend org.eclipse.persistence.internal.helper.ConversionManager).
and override the method convertObjectToBoolean().
To enable the usage of your own conversion manager instance in eclipselink, use a SessionCustomizer and invoke session.getPlatform().setConversionManager()
However, when looking at the source code of this method it seems that the support of the t and f literals is already implemented (at least in eclipselink 2.3.3). But maybe there's a bug?
It's may be worth debugging this method while your application is running to really see what's going on there.
This question already has answers here:
What is reflection and why is it useful?
(23 answers)
Closed 6 years ago.
I was just curious, why should we use reflection in the first place?
// Without reflection
Foo foo = new Foo();
foo.hello();
// With reflection
Class cls = Class.forName("Foo");
Object foo = cls.newInstance();
Method method = cls.getMethod("hello", null);
method.invoke(foo, null);
We can simply create an object and call the class's method, but why do the same using forName, newInstance and getMthod functions?
To make everything dynamic?
Simply put: because sometimes you don't know either the "Foo" or "hello" parts at compile time.
The vast majority of the time you do know this, so it's not worth using reflection. Just occasionally, however, you don't - and at that point, reflection is all you can turn to.
As an example, protocol buffers allows you to generate code which either contains full statically-typed code for reading and writing messages, or it generates just enough so that the rest can be done by reflection: in the reflection case, the load/save code has to get and set properties via reflection - it knows the names of the properties involved due to the message descriptor. This is much (much) slower but results in considerably less code being generated.
Another example would be dependency injection, where the names of the types used for the dependencies are often provided in configuration files: the DI framework then has to use reflection to construct all the components involved, finding constructors and/or properties along the way.
It is used whenever you (=your method/your class) doesn't know at compile time the type should instantiate or the method it should invoke.
Also, many frameworks use reflection to analyze and use your objects. For example:
hibernate/nhibernate (and any object-relational mapper) use reflection to inspect all the properties of your classes so that it is able to update them or use them when executing database operations
you may want to make it configurable which method of a user-defined class is executed by default by your application. The configured value is String, and you can get the target class, get the method that has the configured name, and invoke it, without knowing it at compile time.
parsing annotations is done by reflection
A typical usage is a plug-in mechanism, which supports classes (usually implementations of interfaces) that are unknown at compile time.
You can use reflection for automating any process that could usefully use a list of the object's methods and/or properties. If you've ever spent time writing code that does roughly the same thing on each of an object's fields in turn -- the obvious way of saving and loading data often works like that -- then that's something reflection could do for you automatically.
The most common applications are probably these three:
Serialization (see, e.g., .NET's XmlSerializer)
Generation of widgets for editing objects' properties (e.g., Xcode's Interface Builder, .NET's dialog designer)
Factories that create objects with arbitrary dependencies by examining the classes for constructors and supplying suitable objects on creation (e.g., any dependency injection framework)
Using reflection, you can very easily write configurations that detail methods/fields in text, and the framework using these can read a text description of the field and find the real corresponding field.
e.g. JXPath allows you to navigate objects like this:
//company[#name='Sun']/address
so JXPath will look for a method getCompany() (corresponding to company), a field in that called name etc.
You'll find this in lots of frameworks in Java e.g. JavaBeans, Spring etc.
It's useful for things like serialization and object-relational mapping. You can write a generic function to serialize an object by using reflection to get all of an object's properties. In C++, you'd have to write a separate function for every class.
I have used it in some validation classes before, where I passed a large, complex data structure in the constructor and then ran a zillion (couple hundred really) methods to check the validity of the data. All of my validation methods were private and returned booleans so I made one "validate" method you could call which used reflection to invoke all the private methods in the class than returned booleans.
This made the validate method more concise (didn't need to enumerate each little method) and garuanteed all the methods were being run (e.g. someone writes a new validation rule and forgets to call it in the main method).
After changing to use reflection I didn't notice any meaningful loss in performance, and the code was easier to maintain.
in addition to Jons answer, another usage is to be able to "dip your toe in the water" to test if a given facility is present in the JVM.
Under OS X a java application looks nicer if some Apple-provided classes are called. The easiest way to test if these classes are present, is to test with reflection first
some times you need to create a object of class on fly or from some other place not a java code (e.g jsp). at that time reflection is useful.