You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/07/12 11:04:38 UTC
Configuration initialization
We all should know that Configuration Composite is an Entity, read from an
EntityStore and runtime modifiable just like any Entity.
We also know that if it is not found in the Entity Store, the value is read
from a properties file, named after the identity of the Service Composite
the configuration belongs to.
I am now adding that in addition to Properties files, the file can be read
via ValueSerialization instead. I am also adding that YAML is a format we
intend to support (I really like that format for Config data).
But currently there is no YAML ValueSerialization extension available. If
someone feels itchy to help out; Creating a ValueSerialization extension
for YAML, with the help of SnakeYaml or YamlBeans.
Since the code is virtually the same inside the Configuration, I will rely
on this will get done sooner or later, and my tests are only covering JSON
and XML for now.
Hopefully done today.
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Configuration initialization
Posted by Niclas Hedhman <ni...@hedhman.org>.
Interesting thought... So, "persistence" is a derived from "operations" ?
And there is no primary purpose?
Timeseries is for me the effective storage of timestamped values that
changes often over time. DBs like Cassandra are optimized to retrieve a
slice in time of consequetive data points.
On Mon, Jul 13, 2015 at 6:26 PM, Kent Sølvsten <ke...@gmail.com>
wrote:
> I Think i have misunderstood the intention behind timeseries support then.
> I was more thinking of timeseries as derived values - the same way that the
> indexing May be considered derived from the entity store. And just like in
> some architectures the entity may be considered derived from an eventstore.
> Den 13/07/2015 15.59 skrev "Niclas Hedhman" <ni...@hedhman.org>:
>
> > On Mon, Jul 13, 2015 at 1:58 PM, Paul Merlin <pa...@nosphere.org> wrote:
> >
> > >
> > > > Any thoughts?
> > >
> > > I'm all in favor for going towards "Entity=Identity+Value". In the end,
> > > this will allow us to drop a bunch of code as EntityState serialization
> > > in EntityStores is pretty different than ValueSerialization (was
> already
> > > before I rewrote ValueSerialization for 2.0). And I don't see the need
> > > for theses differences.
> > >
> >
> > Yes, I have also been thinking about that.
> >
> > Potentially the EntityStore SPI could become somewhat simpler.
> > a. "Here is the new Value" per entity, in a two phase process...
> > b. EntityStore could throw the whole Value into the timeseries store,
> > maybe optimized for cases where a single Property is in the Entity.
> >
> > My guess is that Indexing/Query might also benefit from such change.
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Configuration initialization
Posted by Kent Sølvsten <ke...@gmail.com>.
I Think i have misunderstood the intention behind timeseries support then.
I was more thinking of timeseries as derived values - the same way that the
indexing May be considered derived from the entity store. And just like in
some architectures the entity may be considered derived from an eventstore.
Den 13/07/2015 15.59 skrev "Niclas Hedhman" <ni...@hedhman.org>:
> On Mon, Jul 13, 2015 at 1:58 PM, Paul Merlin <pa...@nosphere.org> wrote:
>
> >
> > > Any thoughts?
> >
> > I'm all in favor for going towards "Entity=Identity+Value". In the end,
> > this will allow us to drop a bunch of code as EntityState serialization
> > in EntityStores is pretty different than ValueSerialization (was already
> > before I rewrote ValueSerialization for 2.0). And I don't see the need
> > for theses differences.
> >
>
> Yes, I have also been thinking about that.
>
> Potentially the EntityStore SPI could become somewhat simpler.
> a. "Here is the new Value" per entity, in a two phase process...
> b. EntityStore could throw the whole Value into the timeseries store,
> maybe optimized for cases where a single Property is in the Entity.
>
> My guess is that Indexing/Query might also benefit from such change.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
Re: Configuration initialization
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Jul 13, 2015 at 1:58 PM, Paul Merlin <pa...@nosphere.org> wrote:
>
> > Any thoughts?
>
> I'm all in favor for going towards "Entity=Identity+Value". In the end,
> this will allow us to drop a bunch of code as EntityState serialization
> in EntityStores is pretty different than ValueSerialization (was already
> before I rewrote ValueSerialization for 2.0). And I don't see the need
> for theses differences.
>
Yes, I have also been thinking about that.
Potentially the EntityStore SPI could become somewhat simpler.
a. "Here is the new Value" per entity, in a two phase process...
b. EntityStore could throw the whole Value into the timeseries store,
maybe optimized for cases where a single Property is in the Entity.
My guess is that Indexing/Query might also benefit from such change.
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Configuration initialization
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> We all should know that Configuration Composite is an Entity, read from an
> EntityStore and runtime modifiable just like any Entity.
>
> We also know that if it is not found in the Entity Store, the value is read
> from a properties file, named after the identity of the Service Composite
> the configuration belongs to.
>
> I am now adding that in addition to Properties files, the file can be read
> via ValueSerialization instead. I am also adding that YAML is a format we
> intend to support (I really like that format for Config data).
>
> But currently there is no YAML ValueSerialization extension available. If
> someone feels itchy to help out; Creating a ValueSerialization extension
> for YAML, with the help of SnakeYaml or YamlBeans.
>
> Since the code is virtually the same inside the Configuration, I will rely
> on this will get done sooner or later, and my tests are only covering JSON
> and XML for now.
I took a couple hours to start a YAML serialization extension. Both
SnakeYaml and YamlBeans gave me headhaches when it came to switching
from pull-parsing to tree-parsing for deserialization. Looks like theses
libraries are not built for advanced usecases. I'll need some more time
to come up with something usable.
Niclas Hedhman a écrit :
> And to make this more "integrated", I am introducing
>
> ModuleAssembly.configurations()
>
> since otherwise people will be confused that both a entity and a value
> needs to be declared.
>
> (Actually, this speaks even more in favor of proposal to
> "Entity=Identity+Value")
>
> The assembly will take care of duplicating the declared types as both
> entities and values, so there won't be a ConfigurationInstance type, at
> least not in 2.1.
>
> Any thoughts?
I'm all in favor for going towards "Entity=Identity+Value". In the end,
this will allow us to drop a bunch of code as EntityState serialization
in EntityStores is pretty different than ValueSerialization (was already
before I rewrote ValueSerialization for 2.0). And I don't see the need
for theses differences.
/Paul
Re: Configuration initialization
Posted by Niclas Hedhman <ni...@hedhman.org>.
And to make this more "integrated", I am introducing
ModuleAssembly.configurations()
since otherwise people will be confused that both a entity and a value
needs to be declared.
(Actually, this speaks even more in favor of proposal to
"Entity=Identity+Value")
The assembly will take care of duplicating the declared types as both
entities and values, so there won't be a ConfigurationInstance type, at
least not in 2.1.
Any thoughts?
On Sun, Jul 12, 2015 at 12:04 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> We all should know that Configuration Composite is an Entity, read from an
> EntityStore and runtime modifiable just like any Entity.
>
> We also know that if it is not found in the Entity Store, the value is
> read from a properties file, named after the identity of the Service
> Composite the configuration belongs to.
>
> I am now adding that in addition to Properties files, the file can be read
> via ValueSerialization instead. I am also adding that YAML is a format we
> intend to support (I really like that format for Config data).
>
> But currently there is no YAML ValueSerialization extension available. If
> someone feels itchy to help out; Creating a ValueSerialization extension
> for YAML, with the help of SnakeYaml or YamlBeans.
>
> Since the code is virtually the same inside the Configuration, I will rely
> on this will get done sooner or later, and my tests are only covering JSON
> and XML for now.
>
> Hopefully done today.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java