novoda / sqlite-analyzer Goto Github PK

When you create a table with a NOT NULL field and a view on that table

E.g.:

CREATE TABLE 'book' (
  book_number INTEGER NOT NULL
)

CREATE VIEW 'book_view' AS SELECT * FROM book;

The generated BookView.getBookNumber(cursor) is actually using boxed primitives and checking for null (and returning null if cursor.isNull(index) is true, which is never going to be the case) while the class Book.getBookNumber(cursor) is returning an int as expected.

I still think this should be part of the SQLiteProvider, perhaps with a build toggle if you want to opt in or not.

What are the positives for keeping it separate?

What are the positives for merging with SQLiteProvider?

As mentioned in #31 this project should adopt the git flow branching model for easier division between release and development sources.

For example:
CREATE VIEW IF NOT EXISTS "TABLE_VIEW" AS SELECT TABLE1._id, TABLE2.VALUE1, TABLE1.VALUE1 FROM TABLE1 JOIN TABLE2

Improve the Simple Useage section to show more the power & benefit of using this lib

The plugin assumes there are applicationVariants

Error:Could not find property 'applicationVariants' on com.android.build.gradle.LibraryExtension_Decorated@6f742874.

We have been using this code generator for quite a while now. We have been using the following filename convention:

app.db_upgrade_<oldversion>_<newversion>.sql

One could argue if that is a sensible name but thats where we ended up with some time ago and it worked fine. Until travis decided to update their images with updated os / java.

After investigation it turned out that since the travis update the migration files where executed in the wrong order.

I tracked it down to:
https://github.com/novoda/sqlite-analyzer/blob/0.3.2/analyzer/src/main/java/com/novoda/sqlite/NumberedFilesComparator.java

Which assumes that the migration files are prefixed with <number>_. In our case the mentioned comparator would always return 0 and thus rely on the order of File.listFiles() which is not deterministic and results might have changed due to OS / openjdk vs oraclejdk / java version changes.

I think its good that users should to be aware of this requirement. We renamed the files now. But a more logical comparator would be better I think.

At the moment, views are forced to SELECT DISTINCT and manually select columns when duplicated names are found, such as _id

These duplicated columns should reuse the existing getters/setters and fields

There should be a flag that enables generating SQLOpenHelper class based on migrations files (similar to sqlite provider)

For the migrations/1_setup.sql file below, the generated class ignored _id. Is this intentionally left out, or is it because it begins with _?

CREATE TABLE IF NOT EXISTS 'GALLERY_ITEM'
    (_id TEXT PRIMARY KEY UNIQUE,
    title TEXT,
    description TEXT,
    page_views INTEGER,
    url TEXT,
    uploader TEXT,
    upvotes INTEGER,
    downvotes INTEGER,
    score INTEGER,
    is_album INTEGER,
    cover_image_id TEXT,
    album_layout TEXT,
    num_images INTEGER,
    image_mime_type TEXT,
    is_animated INTEGER,
    width INTEGER,
    height INTEGER,
    size_bytes INTEGER,
    bandwidth_bytes INTEGER,
    delete_hash TEXT,
    submission_datetime TEXT,
    first_synced_datetime TEXT,
    last_synced_datetime TEXT);

The Android gradle plugin uses generated/source as the folder for generated source.

Change SqliteAnalyzerPlugin.groovy

Domain objects should have a toContentValues method to reduce the work of Marshallers and make the mapping explicit.

the sqlite INTEGER type can be up to 8-bytes long so can be a short, int, or long, but currently SQLite will only generate a int setter - could we add long setters too?

When you look at the code generated by this tool, you notice that the getters and setters look like this:

    public static int getId(android.database.Cursor cursor) {
        int index = cursor.getColumnIndexOrThrow("_id");
        return cursor.getInt(index);
    }

    public static void setId(int value, android.content.ContentValues values) {
        values.put("_id", value);
    }

They're using hardcoded strings to address the columns instead of using the corrects constants that are available in DB.Columns.[TableName].

Just been reading these droidcon slides, it's a nice idea for the contract to the content provider. i.e. what generated code to generate when sqliteAnalyzer runs

check it out

https://speakerdeck.com/mathieu_calba/power-your-app-with-content-provider?slide=23

Is it possible to prefer primitives to boxing?