It has been good couple of mornings, and most smaller issues for 3.0 has
been ticked off.
And that lands us with ONE issue left, and that is the Indexing-SQL one.
I will take another stab at it now, but if I can't figure this out, I am
inclined to drop dev-status to 'beta' and it will not be released. Any and
all help is highly appreciated.
On Sat, Apr 8, 2017 at 5:17 AM, Paul Merlin <paulmer...@apache.org> wrote:
> Hey,
>
> Yay for the upcoming 3.0-RC1!
>
>
> Le 2017-04-07 17:54, Niclas Hedhman a écrit :
>
>> Hi,
>> I want to push hard for a release at end of next week. I am looking
>> through
>> the remaining 3.0 marked issues, and
>>
>> Timeseries --> postpone
>>
>
> OK
>
> Entity = Identity+Value --> Postpone indefinitely (too much consequence)
>>
>
> We can look at this one in very different ways and see small increments
> that can give us some goodness without eating the whole cake. What I would
> like us to do quickly, and preferably for 3.0, is to change how Entity
> state is serialized in our EntityStore SPI helpers.
>
> Today, the "value" part of an EntityState is mixed with entity aspects:
>
> {
> reference: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> properties: {..},
> associations: {..},
> manyassociations: {..},
> namedassociations: {..}
> }
>
> I'm thinking about persisting entities with the following structure
> instead:
>
> {
> identity: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> value: { // Exact same state (de)serialization as values
> myProperty: {..},
> myAssoc: "..",
> myManyAssoc: [..],
> myNamedAssoc: {..}
> }
> }
>
> This is quite simple to change, simplifies a lot of code and I'm willing
> to push that forward rather quickly.
> I already have a local experiment of this change.
> BUT, this is a breaking change of the storage format so before doing so
> I'd like to know what do you all think.
> 3.0 is a good time to do this. Don't want to wait for 4.0. If we want to
> push a version out prior to that change, then it should be a -ALPHA1
> instead of a -RC1.
>
> Java 9 issues --> postpone, Java 9 is not out yet
>>
>
> OK, everything works without Jigsaw already
> There's only the Riak client that does not support Java 9 yet.
>
> Yeoman generator --> will complete
>>
>
> If we release the generator to npm we need to sort out how to do that the
> ASF way.
>
> ORM --> just postponed, too much effort to release within weeks let alone
>> days.
>>
>
> OK
>
> Pluggable Types --> I don't know that status. Paul? Postpone if needed.
>> (POLYGENE-94)
>>
>
> I answered directly on the issue. Please follow up there.
>
> Mapping in toEntity/toValue --> Will investigate, possibly implement
>> otherwise postpone.
>>
>
> This should not be too complicated, but we can also postpone to 3.1 as an
> API enhancement.
>
> Rhino -> javax.scripting --> working on it.
>>
>
> Cool
>
> Jar Signing --> I don't know, and look at Paul the build master for
>> opinion. (POLYGENE-116)
>>
>
> Postpone! It may be a bit of a can of worms.
>
> OSGi not working --> Postpone (I am secretly giving up on OSGi)
>>
>
> I personally don't use OSGi at all and don't care much.
>
> Cocnerns/SideEffect on methods --> I will investigate, test and document if
>> it works. Otherwise postpone.
>>
>
> OK
>
> POLYGENE-121 + 122 --> would like to fix, IF I knew better what you meant.
>>
>
> Those are minor enhancements we can do in 3.1.
>
> POLYGENE-132 --> Might be a big one. I have not fully understand what Kent
>> was concluding, but might be important.
>>
>
> Kent?
>
> Indexing-SQL --> Really tough one. I don't think I have enough time to fix
>> this. So, do we cut it out of the release and revive it later? Or is there
>> someone volunteering to take a stab at it?
>>
>
> Stan?
>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
