polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Thoughts on Release 3.0
Date Fri, 14 Jul 2017 00:19:46 GMT
On Fri, Jul 14, 2017 at 12:13 AM, Paul Merlin <paulmerlin@apache.org> 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.

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?

> - 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.

Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message