Added getQueryCache to the ObjectContext interface since this is already implemented by BaseContext anyway and makes accessing the cache much easier.

Revised signature for QueryCache.remove(String) to be remove(QueryMetadata) to increase understandability. It was never clear how to use this method before.

Added QueryCache.clearLocalCache method. This is now called automatically at the end of the request-response loop in StatelessContextRequestHandler and by BaseContext.finalize. This will prevent memory leaking from locally cached data in cases where the cache is not configured to expire entries based on time.

Added QueryCache.debugListCacheKeys method to list all keys (prefixed by cache group) in the cache for debugging purposes.

• Useful to run integration tests without installed Postgres DB
• Activation with -DcayenneTestConnection=postgres-docker
• Starts Postgres Docker container before integration test and stops if afterwards
• Sets JDBC connection properties based on dynamic Docker container port allocation

Hey all, I've got a commit (that I plan on using) that I think is useful. I've added an Orderings class which is a subclass of ArrayList, and then added methods to allow chaining of multiple Ordering through Propertys.

So for example:

Person.COMPANY_NAME.asc().then(Person.FIRST_NAME.desc())

Rather than typing:

Arrays.asList(Person.COMPANY_NAME.asc(), Person.FIRST_NAME.desc())

You can chain together Ordering (into an Orderings) or Orderings into other Orderings.

Person.COMPANY_NAME.asc().then(Person.LAST_NAME.asc()).then(Person.FIRST_NAME.asc())

I find it to be convenient and cleaner, but I'm used to this kind of thing in WOnder. :)

Thoughts?

Sadly I didn't get any feedback this time at developer mailinglist. But this shouldn't contain bug anyway.

This pull request serves a setter method for toManyTargets, which is located in the CayenneDataObject (thank Davids advice). Others and me desire such a functionality in the out-of-the-box class gernation, look at user mailinglist.

In difference to addToManyTarget and removeFromManyTarget this method takes a input Collection<? extends DataObject> and an optional boolean delete parameter (default is false) for deletion of DataObjects, which relationships were removed.

The method documentation should be more comprehensible, what the method does and what not.

The superclass.vm generates two setter methods per toMany relationship where the relationName is part of the method name. The delete ommited method sets the deletion parameter to false and calls the other method.

I don't know, if it is a the best idea to serve a deletion parameter to prevent for orphaned DataObjects. Maybe there is a better solution. I didn't implement yet any test classes. This has still to be done.

It would be happy if you would include my code into your project! Thanks Johannes

This is an experimental implementation of a Db operations sorter that builds a directed graph and uses topological sort to get the final order of operations. This sorter can correctly order meaningful PK intersections (i.e. delete/insert rows with the same primary keys). Moreover, it opens a possibility to automatically break cycles in DB operations.

Cgen - Avoid class loader issues causing missing classes; don't swallow missing class errors completely

It took me almost a full day to find where an exception was being swallowed which would have indicated the problem here. Whatever class loader is being used by Cgen (AdhocObjectFactory) is not picking up classes that are available in the default class loader - namely all the Joda classes, like org.joda.time.LocalDateTime.

This change will make it fallback to using the default class loader if a class is not found, and will log a single line WARNing if the class isn't found by either class loader.

I'm trying out 4.2.M1 snapshot in order to provide testing feedback.

These changes aren't really meant to be applied directly, but to provide feedback into the issues I'm having.

1. Joda time support is lacking in the class generation templates. I understand this is deprecated now, but since it hasn't been removed yet it should still work. Thinking ahead to the future there will need to a way for third parties to integrate Joda support into cayenne without having to create a hard fork. This doesn't appear to currently be possible - at least I don't know how to provide an additional Module to cgen via ant that could provide PropertyDescriptorCreator changes.

2. I need to have a method like PropertyUtils.propertyTypeDefinition exposed so I can utilize it in my templates. The refactoring to move logic into PropertyUtils makes the templates clean and simple, but users need access to smaller pieces as well.

3. Using "between" expressions on Joda time DateProperty instances fails. This is a bug that still needs to be fixed. I don't know where to start on this one.

4. Ant's cgen task was completely broken. I doubt this is the correct fix, but it does get it running again.

Solution description:

1. Package "/cayenne-tools/src/main/java/org/apache/cayenne/tools/dbimport/config" is responsible for loading configuration from different sources (ant, maven, external reversengineering file) and transform(see FiltersConfigBuilder) into convenient format for DbLoader (see FiltersConfig). It is mean that FiltersConfig is a key interface in interaction between tools and server modules.

2. FiltersConfig is a map (DbPath -> EntityFilter) DbPath = Catalog/Schema/Table EntityFilter = Table/Column/Procedure Filters

3. DbLoader builds DbPath for each object, takes filter for this path (filter can aggregate a number of defined in config filters, see FiltersConfig.filter(DbPath)), call isInclude in order to figure out should we include this object or not. DbLoader should interact only with DbPath, FiltersConfig, EntityFilter and Filter interface.

4. Filter interface was designed in order to encapsulate all filtering logic for each specific entity and provide flexibility extend/override this mechanism. For each db object we are calling "isInclude" once and only in one place where filtering applied. Here I have 2 key classes: Filter interface and FiltersFactory.

1. make token name a constructor parameter and remove all other implementations of this method
2. I've created builders for domain objects (i.e. DataMap, Db\Obj Entity, Db\Obj Attribute, ...) and Factory for all builders; Main goal to provide easy way of construction objects and fill them partially with only data that necessary for test case, everything else required to make object valid will be generated randomly.
3. DbMergerTest - test correct identification of DbToModel changes
4. TokensReversTest - test compliance with the invariant token.reverse.reverse == token
5. TokensToModelExecution - test application correctness of DbToModel tokens
6. new dependency datafactory - in order to use random data in tests where exact value not really important

This PR contains a simple JSON parser that could be used to normalize and compare JSON values to exclude time-consuming SQL updates caused by different formatting of JSON strings.

JSON parser is not intended for any other use-cases except for fast values comparison.

Here are simple benchmark results comparing Cayenne's specialized implementation with some widely used libraries. Compare call in all cases is basically parsing two values + equals() call.

Benchmark                         Mode  Cnt   Score   Error  Units
GsonBenchmark.compare             avgt   12  89.533 ± 1.483  us/op
GsonBenchmark.read                avgt   12  39.398 ± 0.271  us/op
JacksonBenchmark.compare          avgt   12  80.887 ± 0.358  us/op
JacksonBenchmark.read             avgt   12  38.201 ± 0.347  us/op
JsonTokenizerBenchmark.compare    avgt   12  79.381 ± 0.722  us/op
JsonTokenizerBenchmark.read       avgt   12  20.126 ± 0.114  us/op
JsonTokenizerBenchmark.normalize  avgt   12  38.148 ± 0.554  us/op

Fixing CAY-2379 by focusing the ObjEntity after the undo RemoveAttributeUndoableEdit action

• Divided and set public access to viewCounterpartEntity method in DbEntityCounterpartAction to be able to switch to the ObjEntity from RemoveAttributeUndoableEdit class.
• Added focusObjEntity method to RemoveAttributeUndoableEdit class
• Invoking focusObjEntity method inside undo method, in the section doing the attribute restitution for ObjEntity type

The feature was developed for work with case-sensitive naming (e.g. "name", "Name", "NAME"). Added a button for using case-sensitive naming in modeler. The useCaseSensitive option allows to have case sensitive naming (for tables, attributes etc) in database, if DB supports it, and passes its initial state. Added quoted identifier in loaders. Added asciidoc and test for case-sensitive naming. An example of naming that can be passed from the database (this is not an example of the correct naming rules but it shows program capabilities): Was fixed tokens creating and tests for SQLite because this database hadn't supported column modifying. https://www.sqlite.org/omitted.html

Description

Test org.apache.cayenne.reflect.PojoMapperTest.testObjectCreation will fail under NonDex which detects flakiness under non-deterministic environment.

To reproduce:

mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex \
    -pl cayenne-server \
    -Dtest=org.apache.cayenne.reflect.PojoMapperTest#testObjectCreation

Issue

In testObjectCreation, the object creation depends on the following logic:

Field[] declaredFields = type.getDeclaredFields();
this.setters = new MethodHandle[declaredFields.length];
int i = 0;
for(Field field : declaredFields) {
        ...
        setters[i++] = lookup.unreflectSetter(field);
}

However, according to the documentation of getDeclaredFields, the function does not guarantee the order of fields and may be different on different JVM.

Simply applying sorting on the fields could guarantee correctness in the testing environment.

Description

Test org.apache.cayenne.util.WeakValueMapTest.testConcurrentModification will fail under NonDex which detects flakiness under non-deterministic environment.

To reproduce:

mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex \
    -pl cayenne-server \
    -Dtest=org.apache.cayenne.util.WeakValueMapTest#testConcurrentModification

Issue

The test code follows the logic below:

Map<String, Integer> map = new WeakValueMap<>(3);
for(Map.Entry<String, Integer> entry : map.entrySet()) {
    if("key_2".equals(entry.getKey())) 
        map.remove("key_2");
}

While WeakValueMap uses HashMap internally, it is not guaranteed for map.entrySet to iterate over the entries under some orders.

The code is expected to thrown ConcurrentModificationException during execution. Under some edge cases, eg: key_2 is traversed and removed last, the test will fail to throw and cause an issue.

The test org.apache.cayenne.log.CompactSlf4jJdbcEventLoggerTest.compactBindings will fail under NonDex tool that detect flakiness under non-deterministic order.

In function CompactSlf4jJdbcEventLogger .collectBindings, the function is declared with the usage of HashMap.

protected void appendParameters(StringBuilder buffer, String label, ParameterBinding[] bindings) {
    ...
    buildBinding(buffer, label, collectBindings(bindings));
}

private Map<String, List<String>> collectBindings(ParameterBinding[] bindings) {
    Map<String, List<String>> bindingsMap = new HashMap<>();
    ...
    bindingsMap.computeIfAbsent(key, k -> new ArrayList<>());
    ...
    return bindingsMap;
}

Whereas the test relies on the result of the HashMap to determine the output, whereas toString should not be able to guarantee the order of insertion.

logger.appendParameters(buffer, "bind", bindings);
assertEquals(buffer.toString(), ...);

I proposed to use LinkedHashMap to keep the hash property while maintaining some kind of ordering.

Fix CAY-2717

Description

Refactor test class DataContextDataChannelEventsIT.java by using Mockito.

Motivation

• Decoupling test class MockChannelListener from production interface DataChannelListener
• Making test condition more clear by removing redundant overridden methods and new fields.
• Use Mockito.verify() to directly verify the behavior of the mocking object and make test condition more explict.

Key changed/added classes in this PR

• Creating mocking object to replace test subclass MockChannelListener, decoupled test from production code.
• Replacing assertation statement by using Mockito.verify() to verify the invocation status of graphChanged(GraphEvent), graphFlushed(GraphEvent) and graphRolledback(GraphEvent).