realm / realm-java Goto Github PK

Implement the view and query library for advanced operations (search & aggregation).

Implement table and view iterator.

Implement the view and query library for advanced operations (search & aggregation).

Code generation: Is it possible to check that files are saved before code generation?

In add() you might as well call insert() instead of duplicating the generated code:

public Phone add(String type, String number) {
try {
long position = size();

        insertString(0, position, type);
        insertString(1, position, number);
        insertDone();

        return cursor(position);
    } catch (Exception e) {
        throw addRowException(e);
    }

}

public Phone insert(long position, String type, String number) {
    try {
        insertString(0, position, type);
        insertString(1, position, number);
        insertDone();

        return cursor(position);
    } catch (Exception e) {
        throw insertRowException(e);
    }

findFirstBoolean
findFirstDate
findAllBoolean
findAllDate

getMixedType
getSubtableSize
clearSubTable

addLong (also add to TableBase)
getSortedView (only TableBase)

not in *.generated as now

Complete the design and implement the library for the other columns types (boolean, date, binary, mixed)

In the QueryExamples the grouping examples are now indented. However the doc-tool needs to be updated to not thow away the indentations.

In Loadlibrary we should try both tightdb, tightdb32, tightdb64 and otherwise come with a helpful message.

In TutorialExample, I added example of how to serialize. That doens't look impressive as I had to use the lowlevel interface because we don't have a templated Table class. Maybe we could add a method in Table to return a factory table or something like that so that Group works better. Or maybe some of the new methods Anirban has added will help.

• There is also an unresolved method call to JNI that I can't understand when I just create a Group.
  Maybe it will be resolved after point 1) above.

implement code generation for the other columns types (boolean, date, binary, mixed)

CodeGenProcessor.calculatePackageName() and/or its caller processAnnotatedElements() assumes that the customers code lives in a Java package. When it does not, the generator fails.

Make the Code generation less "verbose" if possible and easy (since we later change codegeneration method.)

When the code generator runs during compilation from command line, the invocation of FieldSorter from CodeGenProcessor.processAnnotatedElements() fails with messages like the following:

warning: The file doesn't exist: /tmp/temp.pEPW/my.java
Note: Scanning source path '/tmp/temp.pEPW' for table spec 'hilbert'
error: Table spec retrieval failed!
error: Field sorting failed, couldn't find table spec: hilbert

This causes the generator to abort.

When I comment out the invocation, everything works perfectly (assuming a few other reported issues are fixed as suggested).

The following comment suggests that the FieldSorter is a temporary "work around", so maybe we should fix the core problem and get rid of it.

// sort the fields, due to unresolved bug in Eclipse APT
fieldSorter.sortFields(fields, model, sourcesPath);

Implement code generation for nested tables (basic operations).

Nested table "Phone" doesn't work

Improve the type-safety of the query mechanism, by introducing query-only columns for all the column types. Such columns will allow query construction, but not aggregation or projection, so the following statement won't be possible:

persons.firstName.is("X").or().salary.set(1234);

Apparently, there is a separate step in the build process that transforms the templates of the code generator from individual files into strings inside a Java class.

Why did we do that?

In my opinion, it serves only to complicate the build process.

Why don't we simply include the template files inside the JAR file? One would then have to use getResource() or getResourceAsStream() on Class or ClassLoader.

Code generation: Can you automatically refresh project after code generation

The aggregations max, min, sum etc don't work - all return 0.

AbstractAnnotationProcessor.writeToSourceFile(), joins a package name with a class name using a "/" rather than a ".". This causes the generator to produce an invalid name for the generated source file, which in turn causes the generator to abort.

Implement code generation for column list retrieval.

Replace the improvised column types with the real types from Core JNI API v1.1.

Change name: query() should be changed to where().

Currently, classes that are used to declare tables must have uncapitalized names. This is because the code generator generates a cursor class with the same name except that in this case it is capitalized.

I don't like having to write classes with lower case names, and I fear that a lot of Java programmers are going to hate us for it.

I suggest that we either:

• Rename the cursor class from Employee to EmployeeCursor or EmployeeRow, and thereby allowing for the declaration class to be renamed from 'employee' to Employee.
• Rename the declaration class from 'employee' to EmployeeRow, or EmployeeDecl, or EmployeeSpec.

In the latter case, the code generator would then strip off the suffix. It might even be made to recognize and strip off any of the three mentioned suffices. Since the declaration table is not actually used for anything, currently, the prettyness of its name should not matter too much.

On the other hand, the declaration class could be made to have some useful purposes, for example, we might want to allow something like the following (this assumes that the declaration class is renamed to 'Employee' and the cursor class is renamed to 'EmployeeRow'):

public void insertEmployees(Set<Employee> employees)
{
    for (Employee employee: employees) {
        employeeTable.add(employee);
    }
}

and

public Set<Employee> extractEmployees()
{
    Set<Employee> employees;
    for (EmployeeRow row: employeeTable) {
        employees.add(row.getEmployee());
    }
    return employees;
}

In my opinion, the code generator should not be part of tightdb.jar, because it is only needed during compilation of the customers Java code. When the customer deploys the code, they still need to include tightdb.jar, but there is no longer any need for the generator.

I suggest we produce two JARs:
tightdb.jar
tightdb-codegen.jar

In Example (that I have included in tightdb/java2) there are a few things that doesn't work. They are mentioned in comments.

Warn/Error if any unsupported types are used in a @table class.

Abstract query methods: count, average, sum, max, min is missing.

I get a warning when the annotation processor runs because it declares that it does not understand Java source format beyond version 6.

In com/tightdb/generator/CodeGenProcessor.java:

@SupportedSourceVersion(SourceVersion.RELEASE_6)

should probably be changed to

@SupportedSourceVersion(SourceVersion.RELEASE_7)

Of course, we can only make this change if our processor actually understands version 7 syntax properly. If not, we must update the processor.

With a cursor, obtaining the row number (with getPosition() ), fails. Returns 0 even for last row.

What was it with the JDK6 dependency? How can we also support JDK7?

tightdb_java2/tightdb_jni/src/util.hpp defines an anonymous variadic macro. Since they are not part of C++03, we should not use them.

Note: Anonymous variadic macros were introduced in C99 as well as C++11.

When code is generated 'on the fly' during compilation, it is not possible to write something like this in the application code:

import my.application.generated.*;

Because there is nothing inside a package of that name initially. If you try, you will get a compile time error.

This effectively forces you to use fully qualified names when referring to any of the generated classes:

my.application.generated.MyTable = new my.application.generated.MyTable();

Way too painful!

Changing the generator such that it no longer appends ".generated" to the package name works very well in my tests, so why don't we simply do that?

Here is my test code:

package my.application;

import com.tightdb.*;
import com.tightdb.lib.Table;

public class Test {

    @Table
    class hilbert {
        String fido;
    }

    @Table
    class banach {
        String type;
        String number;
    }

    public static void main(String[] args)
    {
        SharedGroup db = new SharedGroup("/tmp/test.tightdb");
        try {
            WriteTransaction transact = db.beginWrite();
            try {
                BanachTable banach = new BanachTable(transact);
                banach.add("John", "Doe");
                transact.commit();
            }
            catch (Throwable e) {
                transact.rollback();
                throw e;
            }
        }
        finally {
            db.close();
        }
    }
}

I don't much like the "lib" part of

import com.tightdb.lib.Table;

First of all, the word "lib" does not really say anything that would help the customer understand why Table would be located there rather than in "com.tightdb". Secondly, I believe it is a very small change to eliminate it, since Table is the only class that the customer is likely to ever have to refer to in that package.

If we moved the Table annotation class to com.tightdb, the customer could simply write

import com.tightdb.*;

For now he needs at least

import com.tightdb.*;
import com.tightdb.lib.Table;

Another improvement (though less attractive in my opinion) would be to move Table to "com.tightdb.annotations", it seems that convention is fairly widespread:

import com.tightdb.*;
import com.tightdb.annotations.Table;

Complete the design and implement the library for nested tables.

Code generation should generate the code under the project instead of com.tightdb.generated

Query "2b" doesn't work

1. Integrate JNI changes from tightdb/Java.
2. All index parameters are now changed from int to long
3. Multiple new methods are available. So they should propagate to the highlevel interface

Introduce table-or-view-specific column for all column types, to provide column operations for a list of records - aggregation, projection, etc. and disable cursor-specific operations. For example, the get() operation should return a list of values, instead only one.

Methods like insertXXX(), insertDone() etc should now be accessible by the generated Tables in highlevel API since the generated insert() should be used instead.
There are likely other methods visible that should be hidden as well.

Improve the type-safety of the cursor column operations, by introducing cursor-specific columns for all the column types. Such columns will allow only column operations for a single cursor, so the following statement won't be possible:

persons.at(2).firstName.min("X")

Migrate (table declaration etc.) to v1.1 of the Core JNI API:

• hand-written example,
• code generator.

Write JavaDocs for the public API classes.

FindUnique() - I don't quite get the idea with the method when you get exceptions when it doesn't "match".

• For now I removed it in the example, since this one we include to customers.

Design and implement the aggregation and manipulation operations for all the table-or-view-specific column types, e.g. getAll(), setAll(), etc.