Digest for jooq-user@googlegroups.com - 3 updates in 3 topics

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Digest for jooq-user@googlegroups.com - 3 updates in 3 topics

http://groups.google.com/group/jooq-user/topics mailing list
[hidden email]: Oct 15 04:48PM -0700

Sometimes, I just want to answer the question "where do I use this table"?
 
I'd like to be able to go to the place where that table is defined and do a
"show usages".
But my IDE (IntelliJ) will only find the references to the specific kind of
reference I'm using, JOOQ declares these "table references" in multiple
places.
 
That I know of, there are at least three ways table (or views, etc.)
references are declared in JOOQ.
 
1) use the static constant in Tables class -
table = example.db.Tables.ACCOUNT
 
 
2) static constant in the concrete TableImpl subclass -
table = example.db.tables.Account
 
 
3) instantiate the concrete subclass -
table = new Account()
 
When I do "find usages" in IntelliJ, it only finds references to the one
specific way that my cursor happens to be on.
 
Does anyone know of a way where I can ask my IDE "what are all the places
the account table is used in the codebase".
I'm looking for a fast / easy way here that I can do this rapidly, many
times on all sorts of different objects - "grepping" or other text based
scripting is really not what I want.
 
Failing an IDE way (which I think might not exist) - is there a JOOQ
feature that can help with this?
 
For example, can I tell JOOQ not to generate the static constants, such
that using the Account constructor is the only way to refer to the table?
It would be less convenient - but that's fine, being able to easily know
all places in the code that refer to a table would be worth that price to
me.
Failing existince of a JOOQ feature to help with this, it wouldn't be too
hard for me to remove the features during the code generation stage - but
would that even do the job though? Are the above three "reference types"
the only code-based ways to refer to DB objects, or other there other ways
I don't know about yet?
 
----
 
Yes, I understand this won't help me with views/functions, etc. that are
textually defined to use tables etc.
I'm aware I could put in place some kind of static analysis to enforce
usage of a single type of table reference. But I'm asking if I can use
JOOQ to eliminate the possibility of using different types.
 
I am using JOOQ 3.9.3 and Postgres.
My config settings are:
 
relations("true")
records("true")
fluentSetters("true")
deprecated("false")
pojos("false")
immutablePojos("false")
pojosEqualsAndHashCode("true")
Niclas Hedhman <[hidden email]>: Oct 15 06:37PM -0700

Version: 3.10.1
Postgres 9.6 server
JDBC Driver: org.postgresql:postgresql:42.1.4
 
T
 
The testcase found below will not work. It will say
 
Caused by: org.postgresql.util.PSQLException: ERROR: schema "POLYGENE"
does not exist
 
when trying to create the table.
 
Further looking, when the commit() is issued inside the
dsl.createSchema( "POLYGENE" ).execute();
 
the transaction state is in "IDLE" mode, and the commit is not executed.
The reason for that is that some ROLLBACK has been executed as part of a
close() that I don't understand. The commit() not executing is silently
ignored in driver, and nothing happens. Hence the failure on the creation
of the table.
 
Ok, so that might have been a bug.
 
Swap the comments of
 
DataSource dataSource = dbcpDataSource( host, port );
// DataSource dataSource = rawDataSource(host,port);
 
 
and the test case works. Now, that could possibly be that there is an
autoCommit going on. I have not investigated that.
 
Swap those comments back to original, and the test fails (after manually
cleaning up the database).
 
Finally, swap the
 
TransactionProvider transactionProvider = new PolygeneTransactionProvider( new ThreadLocalTransactionProvider( connectionProvider, false ) );
// TransactionProvider transactionProvider = new ThreadLocalTransactionProvider( connectionProvider, false );
 
 
and the testcase also works. The wrapper couldn't be simpler, but why does
that cause a failure of this nature? Why is JOOQ checking the instance type
for behavior, instead of having proper methods for it?
 
 
 
 
package org.hedhman.niclas;
 
import javax.sql.DataSource;
import org.apache.commons.dbcp2.BasicDataSource;
import org.jooq.Configuration;
import org.jooq.ConnectionProvider;
import org.jooq.DSLContext;
import org.jooq.Field;
import org.jooq.Name;
import org.jooq.SQLDialect;
import org.jooq.Schema;
import org.jooq.TransactionContext;
import org.jooq.TransactionProvider;
import org.jooq.conf.RenderNameStyle;
import org.jooq.conf.Settings;
import org.jooq.exception.DataAccessException;
import org.jooq.impl.DSL;
import org.jooq.impl.DataSourceConnectionProvider;
import org.jooq.impl.DefaultConfiguration;
import org.jooq.impl.ThreadLocalTransactionProvider;
import org.junit.Test;
import org.postgresql.ds.PGSimpleDataSource;
import org.postgresql.jdbc.AutoSave;
 
 
import static org.apache.polygene.entitystore.sql.TableFields.
tableNameColumn;
import static org.apache.polygene.entitystore.sql.TypesTable.makeField;
 
public class Experiment
{
@Test
public void test1()
throws Exception
{
String host = "127.0.0.1";
int port = 5432;
DataSource dataSource = dbcpDataSource( host, port );
// DataSource dataSource = rawDataSource(host,port);
Settings settings = new Settings().withRenderNameStyle( RenderNameStyle.QUOTED
);
SQLDialect dialect = SQLDialect.POSTGRES;
Schema schema = DSL.schema( DSL.name( "POLYGENE" ) );
 
ConnectionProvider connectionProvider = new DataSourceConnectionProvider(
dataSource );
TransactionProvider transactionProvider = new PolygeneTransactionProvider( new
ThreadLocalTransactionProvider( connectionProvider, false ) );
// TransactionProvider transactionProvider = new
ThreadLocalTransactionProvider( connectionProvider, false );
Configuration configuration = new DefaultConfiguration()
.set( dialect )
.set( connectionProvider )
.set( transactionProvider )
.set( settings );
 
DSLContext dsl = DSL.using( configuration );
 
Field<String> identityColumn = makeField( "_identity", String.class );
Name tableName = DSL.name( schema.getName(), "TESTTABLE" );
 
dsl.transaction( t -> {
dsl.createSchema( "POLYGENE" ).execute();
} );
 
dsl.transaction( t -> {
 
dsl.createTableIfNotExists( tableName )
.column( identityColumn )
.execute();
});
}
private DataSource dbcpDataSource( String host, int port )
throws Exception
{
BasicDataSource pool = new BasicDataSource();
 
String driverClass = "org.postgresql.Driver";
Class.forName( driverClass );
pool.setDriverClassName( driverClass );
pool.setUrl( "jdbc:postgresql://" + host + ":" + port + "/jdbc_test_db" );
pool.setUsername( System.getProperty( "user.name" ) );
pool.setPassword( "ThisIsGreat!" );
pool.setDefaultAutoCommit( false );
return pool;
}
 
private DataSource rawDataSource( String host, int port )
throws Exception
{
PGSimpleDataSource datasource = new PGSimpleDataSource();
datasource.setUser( System.getProperty( "user.name" ) );
datasource.setPassword( "ThisIsGreat!" );
datasource.setAutosave( AutoSave.NEVER );
datasource.setUrl( "jdbc:postgresql://" + host + ":" + port + "/jdbc_test_db"
);
return datasource;
}
 
static class PolygeneTransactionProvider
implements TransactionProvider
{
 
private TransactionProvider delegate;
 
private PolygeneTransactionProvider( TransactionProvider delegate )
{
this.delegate = delegate;
}
 
@Override
public void begin( TransactionContext ctx )
throws DataAccessException
{
System.out.println( "\"------------------------------> begin( " + ctx + "
)" );
delegate.begin( ctx );
}
 
@Override
public void commit( TransactionContext ctx )
throws DataAccessException
{
System.out.println( "------------------------------> commit( " + ctx + " )"
);
delegate.commit( ctx );
}
 
@Override
public void rollback( TransactionContext ctx )
throws DataAccessException
{
System.out.println( "\"------------------------------> rollback( " + ctx + "
)" );
delegate.rollback( ctx );
}
}
}
Lukas Eder <[hidden email]>: Oct 15 11:45PM +0200

Hi Buddhika,
 
I think the notion of synthetic primary keys that you can configure in the
code generator might be the solution to your problem:
https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-synthetic-primary-keys
 
Hope this helps,
Lukas
 
2017-10-15 20:31 GMT+02:00 Buddhika Ekanayake <[hidden email]>
:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].