what about computed columns ... i know we have a views and it is a lots of works since you are using projection parameter from CP.query as columns in db.query without mapper... take a look at my(runtime) generator documentation and search for computed https://selvinlistsyncsample.codeplex.com/documentation ...(also you can add extras to the Column like Column.COLLATE) ...

Create cursorwrappers file for each tables and views. generate cursorwrappers classes that contains methods named with column names. Useful for cursor adapters !

It is arguably most important method for people using custom ContentProvider + SyncAdapter with android:supportsUploading="true", yet there is no helper method for it in generated provider.

This isn't strictly speaking an issue with Android-AnnotatedSQL, but it can be sort-of worked around on ContentProvider level, so I am bringing it to your attention now:

android.database.sqlite.SQLiteException: Can't downgrade database from version 10 to 9
            at android.database.sqlite.SQLiteOpenHelper.onDowngrade(SQLiteOpenHelper.java:307)
            at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:168)
            at android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:231)
            at com.example.ExampleProviderProto.query(ExampleProviderProto.java:148)

The cause is the default SQLiteOpenHelper. It looks rather funny, if you consider, that according to comments at the top of source file getReadableDatabase over getWritableDatabase doesn't make any difference in production OS builds.

GitHub changed the way Markdown headings are parsed, so this change fixes it.

See bryant1410/readmesfix for more information.

Tackles bryant1410/readmesfix#1

Greetings, Is there any way to make your library compatible with Maven based builds? Is there a way to make sure code generation works during compilation like Lombok library does?

Since Beta release of Android Studio the build/ tree has changed a bit (technically since AS 0.6.x release, which includes all relevant changes to gradle plugins). This patch places the generated files into the correct directory.

Позволяет более легко цеплять апт либы. Поддерживает asql, aa, groundy, а также можно указывать сколько угодно кастомных либ

Пример для стандартных либ:

aptlibs {
    annotatedSql {
        version '1.7.8'
    }
    groundy {
        version '1.3'
    }
    androidAnnotations {
        version '2.7.1'
    }
}

Или вот так можно захерачить свою:

aptlibs {
    custom {
        customAnnotatedSql {
            processors = ["com.annotatedsql.processor.provider.ProviderProcessor", "com.annotatedsql.processor.sql.SQLProcessor"]
            groupId 'com.github.hamsterksu'
            artifactIdApt 'android-annotatedsql-processor'
            artifactIdLibrary 'android-annotatedsql-api'
            version '1.7.8'
        }

        customAndroidAnnotations {
            processors = ["com.googlecode.androidannotations.AndroidAnnotationProcessor"]
            groupId 'com.googlecode.androidannotations'
            artifactIdApt 'androidannotations'
            artifactIdLibrary 'androidannotations-api'
            version '2.7.1'

            customArgs { variant ->
                arg "-AandroidManifestFile", "${variant.processResources.manifestFile}"
            }
        }
    }
}

I have encountered a nasty deadlock during debugging some db-related code and traced it down to this thread. So, basically, SQLite is advertised as a multiple-readers-single-writer db, but does not work that way in Android, unless you call beginTransactionNonExclusive instead if beginTransaction. The notifications about changes are delivered in order via ContentResolver, so there should not be any concurrency issues from the first glance.

What possible downsides to doing that can you imagine? Would it make sense to use that method by default in AnnotatedSQL?

Steps to reprodice:

1. Define rawquery as

SELECT AI._id, GROUP_CONCAT(Name, ", ") AS GroupedName FROM ABSTRACTS_ITEM AI JOIN AUTHORS_ABSTRACT AAB ON AI.ID = AAB.ABSTRACTSITEM_ID JOIN ABSTRACT_AUTHOR AAU ON AAU._id = AAB.ABSTRACTAUTHOR_ID GROUP BY tbl._id;

1. Initiate request
2. Build application

Expected result: App successfully is built and request works well

Actual result: App is crashed during build. Error in autogenerated dbschema with errors:

Error:(69, 1903) error: ';' expected Error:(69, 1914) error: expected Error:(69, 1997) error: expected

Let's look at schema with simple join on views. The linked gist won't compile, because using a Schema2 requires a table to be parsed... Which can not be done until @SimpleView, using the Scema2 is parsed.

I see 3 solutions (aside from not using AnnotatedSQL there):

• Hardcode stuff from Schema2 into the contract (not nice, isn't it?);
• Postpone individual tables/views until further compilation passes;
• Simply do not create Schema2 (e.g. #20).

Right now AnnotatedSQL mangles column names during joins by appending "as table_name___column_name" to each column in generated SELECT statement, e.g.

CREATE VIEW nearest as SELECT locations._id as _id, locations.coslat as locations_coslat, locations.sinlat as locations_sinlat...

While occasionally useful and more mistake-proof, this prevents hardcoding column names in really complex statements. Instead the generator should check for duplicate names and rename columns only when necessary. For most purposes it should be enough to maintain a single global list of names and rename columns when any two tables have column with the same name. Otherwise just keep old names.

Hopefully, this won't not introduce any breakage, but just in case you can leave old behavior by default and make it toggleable with apt option.