Neale Upstone
Neale Upstone
Need initial documentation Can use something like the doc formats that Spring Batch etc use, and automatically publish it to the site when generating a new release.
Current API needs tidying up to hide the implementations. The following should work instead: ``` AttributeMatchQuery query = QueryFactory.findMatchesOfType(Item.class).forSubject(subject).withMatchStyle("potentialDates").withMaxResults(10).build(); ``` and ``` AttributeMatchQuery query = QueryFactory.findMatchesOfType(Item.class).forSubjectRef(refToExistingItem).withMatchStyle("potentialDates").withMaxResults(10).build(); ```
It would be good to standardise this without dependency on WWM attributes, returning simple tuples instead. This should work within the DataGenerator within the sample app, and allow simple apps...
Within the database, we need to know a unique key and version for each object, which has historically been provided by passing objects from the database wrapped in a MetaObject....
If we have a database with different entity types, e.g. Cafe, Person, Car (as in current example), then we store them in the same store, and they are currently visible...
e.g. if we use a Java enum, that maps through to form:radiobuttons/checkboxes automatically. We can auto configure based on enum class name for the name of the enumdef Add annotations...
This looks like a quick win for 1.0 for performance and compactness. Looks relatively easy to implement with sacrifice of cross platform support. Longer term protobuf would make sense. For...
Should be able to saturate cores with this quite well. Also introduce ExecutorServiceFactory to centralize on one thread pool
Need to be able to do a query that isn't against something. This means that we need to be able to do a query by providing a ScoreConfiguration object, and...
This would be good to have at first public demo, but not entirely essential, given we can use existing archetype + really minimal config (which is preferable first goal)