On Fri, Jul 14, 2017 at 12:13 AM, Paul Merlin <[email protected]> wrote:
> Niclas Hedhman a écrit : > > 2. Mentioned above; I am suspicious about the SQL Indexer and its > "reindex" > > on start up. I have frequent exceptions on that when working on the > > generator, and although one bug was fixed (thanks Stan) I think there are > > others in the type lookup. One hypothesis I have, which is not confirmed, > > is that "Module" is written into the SQL database, which I think is used > on > > reindexing, and during reindexing that "Module" field becomes the > indexer's > > module, and on the second restart and its indexing things are messed up. > I > > suggest that we do not include the SQL indexer in 3.0 > > +1 > @Niclas: could you create an issue with this? > I don't have it nailed down and getting so frustrated with it, since I think it is on the 3 start or something like that. > > 3. Paul has previously brought up that Extensions are not unified and > > implements different amounts of features, and it is difficult to know > what > > is supported. Solr indexer is a example of something that doesn't support > > much of the Indexing SPI, and is actually addressing a different concern; > > Text Search, which I think should be a separate API in a new Query API > > which I would like to work on for Release 3.2. I suggest that Solr > Indexer > > is dropped from 3.0 > > I'm with Kent on this, the Solr index/query extension has value and its > documentation states clearly what is supported and what is not: > http://polygene.apache.org/java/develop/extension-index-solr.html. > I see no reason to not ship it with 3.0. > Ok, we keep it in. > 4. There will soon be a new SQL Entity Store, and I don't think there is > > any point in keeping the existing one. I suggest (and prefer) that it is > > dropped from 3.0, or at least renamed to something like > > entitystore-legacysql > > What about entitystore-map-sql instead? > It is a MapEntityStore. > We can deprecate and retire it at some point, but the word "legacy" > makes me itchy. > Ok... It is funny that only in the computing is "legacy" something bad. Every other industry and field of achievements the word "legacy" is something to strive for. :-) > Here are some areas I would like to work on next with the tentative > calendar above in mind: > > 3.1 > > - Tooling > - a suite of Gradle plugins: polygene-library, polygene-extension, > polygene-application .. to make it damn easy to setup the build of > Polygene apps > - formalize Extensions vs. Features (reporting, documentation, > testing?) > - reinstate checkstyle checks now that it supports Java 8 > Ok, that would simply fold into the generator? Or is it something to be published separately? 3.2 > > - Polygene runs on Jigsaw > Is Oracle still going ahead with Jigsaw? I thought the EC shot it down? > - Performance testing, some guarantee that we don't introduce > regressions would be awesome > I will offer my new company's resources for this, and it should be available around 3.2 time frame. > - Performance optimisations (e.g. known hot spots in serialization > fixable once Johnzon supports JSR-374) > - Collaboration on the new indexing system / query api is appealing! > I doubt that I can manage a new indexing/querying on my own, and looking forward to heavy collaboration on that. I'll take a look at 'develop' later today. Cheers -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
