Re-igniting this discussion, I think registry based approach is not a
viable solution, as what we store here is pretty complex set of
relationships.
IMO we should come up with a DB design and uses a DB, to store these
information.
On Fri, Jun 20, 2014 at 11:04 AM, Isuru Haththotuwa
wrote:
> AF
On Fri, Jun 20, 2014 at 12:13 PM, chris snow wrote:
> IIRC, a goal of liquibase is to make refactoring database schemas easier
> [1]
>
> ---
> [1] http://www.liquibase.org/documentation/changes/index.html
>
Thanks Chris!
>
> On Fri, Jun 20, 2014 at 6:07 AM, Imesh Gunaratne wrote:
> > +1 for dir
IIRC, a goal of liquibase is to make refactoring database schemas easier [1]
---
[1] http://www.liquibase.org/documentation/changes/index.html
On Fri, Jun 20, 2014 at 6:07 AM, Imesh Gunaratne wrote:
> +1 for direct database approach.
>
> Few points:
> - Registry store resource content as blobs e
+1 to use registry for persisting data than database(s), Can't we use JSON
format rather than RXT or name value pairs since if use name value pairs
when retrieving data from registry will be a costly process?
On Fri, Jun 20, 2014 at 11:09 AM, Udara Liyanage wrote:
> Hi,
>
> Me also feel that it
Hi,
Me also feel that it is better to use the registry rather than maintaining
separate db scripts.
On Fri, Jun 20, 2014 at 11:04 AM, Isuru Haththotuwa
wrote:
> AFAIU writing/reading to/from a shared DB is very convenient when you use
> the registry. We do not need to maintain separate databas
AFAIU writing/reading to/from a shared DB is very convenient when you use
the registry. We do not need to maintain separate database scripts, etc and
worry about migration. In case of a complex data structure like the
topology, the DB schema can be changing rapidly and a nightmare to
maintain.
If
+1 for direct database approach.
Few points:
- Registry store resource content as blobs even though the content format
is text.
- Therefore as Udara has pointed out we will need to write a registry
client to do the migrations if we go with the registry.
- If we use a set of databases (SM, AS, CC),
On Thu, Jun 19, 2014 at 12:35 PM, Nirmal Fernando
wrote:
> I think we should go for databases.
>
Else, a non binary method supported in registry, such as rxt or simple
name-value pairs.
>
>
> On Thu, Jun 19, 2014 at 12:26 PM, Udara Liyanage wrote:
>
>> Hi Chris,
>>
>> In json also if there is a
Agreed. XML/json will give you 'some' flexibility, but serialised objects
give you none.
On 19 Jun 2014 07:57, "Udara Liyanage" wrote:
> Hi Chris,
>
> In json also if there is a it will assign the default value for non
> existing variables when converting from json to java object structure.
> Sti
On Thu, Jun 19, 2014 at 12:05 AM, Nirmal Fernando
wrote:
> I think we should go for databases.
>
I also think we should use a database and we can use an ORM tool. May be we
can use Spring Data [1] also.
[1] http://projects.spring.io/spring-data/
>
>
> On Thu, Jun 19, 2014 at 12:26 PM, Udara Liy
I think we should go for databases.
On Thu, Jun 19, 2014 at 12:26 PM, Udara Liyanage wrote:
> Hi Chris,
>
> In json also if there is a it will assign the default value for non
> existing variables when converting from json to java object structure.
> Still if there is a considerable change in o
Hi Chris,
In json also if there is a it will assign the default value for non
existing variables when converting from json to java object structure.
Still if there is a considerable change in object structure, we have to
perform additional work in migration.
Say we have introduced an variable x,
Hi Udara, I'm not sure of the situation with JSON, but when using XML
it is possible to evolve a schema as long as changes are done in a
backward compatible way. For example, if you add an optional field,
the parsing code will be able to read xml created with and without the
field. However, IIRC
Hi,
One more thing that comes to mind was is there a limitation of the size of
the text that can be stored in registry. When the topology grows, it json
also grows. I assume the registry handles this somehow, but should verify
beforehand.
On Thu, Jun 19, 2014 at 11:15 AM, Udara Liyanage wrote:
Hi Imesh/Dinesh,
Though we used a readable json/xml/text still we can't migrate seamlessly?
When migrating we have to read the old json and convert it it the new
object structure.
Could you please explain how making it readable helps to migrate seamlessly.
On Wed, Jun 18, 2014 at 2:19 PM, Ime
Hi Dinesh,
Great! Please provide your thoughts on the changes required in registry
persistence logic as you progress.
Thanks
On Wed, Jun 18, 2014 at 12:27 PM, Dinesh Bandara wrote:
> Hi,
>
> When I started work on [1] and I thought to persist cartridge
> configuration in JSON format in Strato
Hi,
When I started work on [1] and I thought to persist cartridge configuration
in JSON format in Stratos Manager's registry and observed the above
behavior which does not provide the readability of existing artifacts.
Will work on [2]
[1] https://issues.apache.org/jira/browse/STRATOS-568
[2] htt
Hi All,
In Stratos 4.0.0 Stratos Manager, Cloud Controller and Autoscaler store
their artifacts in registry in binary format (Java objects are serialized
and stored). This might cause problems when migrating an existing Stratos
deployment to a newer version with changes in above artifacts.
Theref
18 matches
Mail list logo
