I'm using a build of ormlite-core from master (commit e653256eefe6ada8bf6a8fe9b52a5d85ac549142) on Android.

I'm getting this runtime exception when creating a table:

java.lang.IllegalArgumentException: Field address1 has maxForeignAutoRefreshLevel set (2) but not foreignAutoRefresh is false
        at com.j256.ormlite.field.FieldType.<init>(FieldType.java:273)
        at com.j256.ormlite.table.DatabaseTableConfig.convertFieldConfigs(DatabaseTableConfig.java:249)
        at com.j256.ormlite.table.DatabaseTableConfig.extractFieldTypes(DatabaseTableConfig.java:116)

The relevant field has this definition:

@DatabaseField
private String address1;

In 4b3a3dda9d07c83c7afa4519f3eb2e642ededbd7 , you changed how the default recursion level is injected. Does this now change the level for all fields? Should there be a check that the field is actually a foreign one?

This problem never occurred for me when using ormlite-core 4.4.8 . I don't ever set the refresh level in my models.

I'm trying to build the master branch of ormlite-core (and ormlite-android) because I need the new commits about CursorLoader and CursorAdapter.

I use ubuntu 14.04. I just cloned the github repo and launched mvn install.

Here is what I get : JavaxPersistenceImpl.java:[6,24] error: package javax.persistence does not exist.

I saw in the pom that the javax.persistence dependency has the scope "test". It may be the cause of the issue. If it is, how did you build until now ?!!

For a more flexible polymorphic design it is preferable to do this

MyClass myInstance;

Dao<Object, Integer> dao = getHelper().getDao(myInstance.getClass()); dao.update(myInstance);

than use a hard-code class type like this

MyClass myInstance;

Dao<MyClass, Integer> dao = getHelper().getDao(MyClass.class); dao.update(myInstance);

The proposed change set allows this.

Given a class:

public class Transaction {
    ...

    @ForeignCollectionField(foreignFieldName = "transaction")
    private Collection<Document> documents;
}

And then working with it using Stream API leaves the acquired connections behind. Happens in number of ways, but simple way to reproduce is:

Transaction transaction = dao.queryForId(id);
Document document = transaction.getDocuments().stream().findFirst().get();

final int numberOfConnections = 3;

// 1 connection for dao.queryForId. And 2! more created during java.util.Spliterators.IteratorSpliterator#estimateSize
verify(connectionSource, times(numberOfConnections)).getReadOnlyConnection(any());

// Expecting that all connections where released, but actually one connection was not (one of the connections acquired during IteratorSpliterator#estimateSize remains acquired)
verify(connectionSource, times(numberOfConnections)).releaseConnection(any());

Reproduced with ormlite 5.6

I'm a little lost trying to figure out the root cause, figured maybe you'd have some idea...

We're running ORMLite on Android, and a few times a day, we're seeing a call to TableInfo.getFieldTypeByColumnName() fail in a seemingly impossible manner:

Caused by java.lang.IllegalArgumentException: You should use columnName 'name' for table organizations instead of fieldName 'name'
       at com.j256.ormlite.table.TableInfo.getFieldTypeByColumnName(TableInfo.java:168)
       at com.j256.ormlite.stmt.StatementBuilder.verifyColumnName(StatementBuilder.java:195)
       at com.j256.ormlite.stmt.QueryBuilder.addSelectColumnToList(QueryBuilder.java:662)
       at com.j256.ormlite.stmt.QueryBuilder.selectColumns(QueryBuilder.java:117)

I'm not sure how you can end up in this state. Based on my reading of getFieldTypeByColumnName(), it essentially:

1. Creates a Map<ColumnName, FieldType> for the table.
2. Tries to return the FieldType that matches the provided ColumnName.
3. If it fails, it tries to figure out if maybe you provided a FieldName instead of a ColumnName.

That all seems reasonable to me; however, in the stack trace it shows the same FieldName and ColumnName. If the error-checking for-loop can find the right FieldType, then why doesn't the Map<ColumnName, FieldType> have it?

We get this crash only intermittently, not consistently, so it's not something fundamentally wrong with the calling code. I suspect some sort of concurrency issue, though I don't see anything obviously wrong here. It could be something with the oddities of SMP on Android. Perhaps the Map creation needs to be synchronized?

We've know we've seen this since ORMLite 5.3, though it's possible we saw it earlier than that (it's just that our crash logs don't go back that far).

Any ideas on how this could happen?

Hello, After I saw the support for UUID native fields, I switched to the 5.0 release. But it seems either it doesn't work or I'm missing something. I have a pojo class with a java.util.UUID ID field and the annotation

@DatabaseField( generatedId=true, dataType=DataType.UUID_NATIVE )

my database has the field

"id" uuid not null primary key default uuid_generate_v4()

but when I try to save an object with

dao.create( myObj )

then I have a PSQLException column "id" is of type uuid but expression is of type character varying.

If I add readOnly = true to the @DatabaseField, then the insert works, but the ID returned by my object after the .create() is not the ID saved in the database.

Am I doing something bad? Is it possible to handle UUID auto-generated ID values on the database ?

Hi @j256

I'm currently using ormlite-core 5.0 and getting a crash on QueryBuilder.orderBy(). My order by column is not being recognized when the language of the device is being set to Turkish.

Here's part of the stack trace:

java.lang.IllegalArgumentException: You should use columnName 'providedId' for table trip instead of fieldName 'providedId' at com.j256.ormlite.table.TableInfo.getFieldTypeByColumnName(TableInfo.java:151) at com.j256.ormlite.stmt.StatementBuilder.verifyColumnName(StatementBuilder.java:183) at com.j256.ormlite.stmt.QueryBuilder.orderBy(QueryBuilder.java:176) at com.mttnow.android.bcd.persistence.dao.TripDao.getQueryBuilder(TripDao.java:151) at com.mttnow.android.bcd.persistence.dao.TripDao.queryForAllOrdered(TripDao.java:84)

Related to https://github.com/j256/ormlite-core/issues/67

Thank you.

Hi

I have suspicion that on fields which are id and are custom type operation create or update doesn't work. Maybe I configured something wrong. Don't want to paste some code snippets. So I've created project which has this situation.

https://github.com/issue-example/ormlite.git on branch issue/create_or_update_on_custom_type

I am re-posting this issue here on github, as there is already an open question in SO. I stumbled upon some strange behavior regarding orderByRaw. I was trying to model this query, which resembles a distinct:

SELECT `occupation` FROM `cards` GROUP BY `occupation` ORDER BY `occupation` IS NULL ASC.

In a populated database, this query should group by the occupation value, and order by the IS NULL value. IS NULL is either 1 or 0, which depends on whether the value is null or not correspondingly. Now if you order by IS NULL value ascending, then you ask SQL to return all the zeroes first, and all the ones in the end, literally giving a result of NULLS in the end. In order to model the above query using ORMlite, I did this:

String column = "occupation"; //This comes from an unknown source
SelectArg selectArg = new SelectArg(SqlType.STRING, column);
qBuilder.selectColumns(column).groupBy(column).orderByRaw("? IS NULL ASC", selectArg);

Apparently one should expect the null values to be returned after all the non-null ones, but instead the query seems to be run as is:

SELECT * FROM `cards` GROUP BY `occupation` ORDER BY ? IS NULL ASC.

The above query is a perfectly valid one. I've never seen a logically valid usage of ? in this context but still it's syntactically correct, and therefore the driver just accepts it without errors, but the ordering is unaffected. I created a JUnit test with an assert test in my github. You can check it here.

Keeping track of changes to classes, maintaining a version number and writing manual 'scripts' in onUpgrade() is error-prone and becomes unwieldy as the number of releases grows.

OrmLite could automate this to varying extents. Initially for add/remove columns, and probably also for changing data type or size where the data is compatible.

An initial implementation could compare the 'create table' statement generated from the Class with the current database table structure and if there is any mismatch: rename the table, create a new table, copy all the data across, then delete the old renamed table.

Later enhancements could analyse the mismatches and generate 'alter table' statements for faster operation but the above might be acceptable for many applications in the meantime.

Bumps log4j-api from 2.0-beta4 to 2.16.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I've got a scenario where a DatabaseTable A has an eager ForeignCollectionField referring to table B, which has a foreign DatabaseField referring to table C, which has a foreign field referring back to table A. When querying for an uncached instance of A, I'm seeing:

1. Check the cache (weak ReferenceObjectCache) for a cached instance when mapping rows and return it https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/stmt/mapped/BaseMappedQuery.java#L49 otherwise:
2. Create a new instance https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/stmt/mapped/BaseMappedQuery.java#L54
3. Iterate resultsFieldTypes https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/stmt/mapped/BaseMappedQuery.java#L58
4. Recursively assign fields, eventually calling createForeignObject to create a new instance of A while iterating the fields on an instance of C https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/field/FieldType.java#L574
5. The instance of A from step 4 is hydrated and added to the object cache https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/field/FieldType.java#L1077
6. The instance of A from step 2 is added to the object cache https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/stmt/mapped/BaseMappedQuery.java#L94

At this point I've got the instance of A from step 2 (and 6) in my object cache along with an instance of C that has a foreign DatabaseField referring to the instance of A from step 4.

I could avoid this particular scenario by lowering maxForeignAutoRefreshLevel on either B's reference to C or C's reference to A, but we add columns to our data model often and I'd rather not consider these possible cycles each time we do this!

So my question is: would it make sense to modify BaseMappedQuery mapRow() to add newly-created instances to the object cache prior to resolving foreign references (i.e., between steps 2 and 3 above)? That way (I think) the subsequent mapRow calls for the foreign references would be find the cached instance from step 2 rather than creating a new instance?

I can also imagine that it might be a bad idea to add partially-hydrated instances to the object cache, so this idea may be a nonstarter!

I used using an updateRaw statement of the form:

marketOrdersDao.updateRaw(
    "INSERT INTO market_orders_temp " + "(" + columnList + ") " + "VALUES " + "(?, ?, ?, ?, ?, ?,...)",
    ... snip ...
    order.getPrice().toString(), // getPrice() returns Double
    ... snip ...
);

For some values of price, specifically ones with exponents, such as 7.527E7. The value would end up in the database as 7.527.

The database in question is my local testing database: PostgreSQL 13.2, compiled by Visual C++ build 1914, 64-bit. However, I didn't see the issue on my production DB PostgreSQL 13.4 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 11.2.1 20211203 (Red Hat 11.2.1-7), 64-bit. Both running the same version of ormlite.

If it's relevant, market_orders_temp is a temp table created within the same transaction (ie, not the same table as the dao that updateRaw is called on).

I was able to work around the issue by using a CompiledStatement directly:

try {
	CompiledStatement compiledStatement = connection.compileStatement(
	  "INSERT INTO market_orders_temp (" + columnList + ") VALUES (?, ?, ?, ?, ?, ?, ...)",
	  StatementBuilder.StatementType.UPDATE,
	  new FieldType[0],
	  DatabaseConnection.DEFAULT_RESULT_FLAGS,
	  false);

	try {
		// Insert changed orders into temporary table
		for (MarketOrdersResponse order : changedOrders) {
... snip ...												
		compiledStatement.setObject(6, order.getPrice(), SqlType.DOUBLE);
... snip ...
		}
	} finally {
		IOUtils.closeThrowSqlException(compiledStatement, "compiled statement");
	}
} finally {
	database.getConnectionSource().releaseConnection(connection);
}

I'm thinking this is some oddity with converting strings to numbers with specific database versions, or possibly differing JDKs?

I need an annotation like @ForeignCollectionField which is for single object @ForeignSingletonField. I tried to make a one-to-one relationship with javax.persistence annotation with my knowledge from jpa, but I guess ormlite doesn't support persistence annotation enough.

If this ormlite is also not possible I'm calling out to the ORMLite developers. It would be great if you add @ForeignSingletonField annotation .

The annatation I want you to add corresponds to @OneToOne in JPA

As I understand it, the recent changes to ORMLite 6.x packages (via shading) the core library.

However, this means that you can no longer use both the JDBC and Android versions side-by-side. This causes compilation issues because the same core classes are included twice.

The reason we do this is because in the main app, we use ormlite-android; but in tests, we use ormlite-jdbc.