On 12/14/2015 03:20 PM, Paulo Ricardo Paz Vital wrote:
On 12/14/2015 01:06 PM, Rodrigo Trujillo wrote:
> This solution works for Kimchi and Ginger now, but I analyzed it a bit
> deeper and I cannot see it as a good long-term solution.
I think the first and most important point you should see here is that
Wok provides the objectstore structure for any plugin wants to use it.
So, since a plugin is using the Wok's objectstore structure, the
solution will works.
Second, this change came from a Ginger and GingerBase issue regarding
the missing 'version' field on their structure, something solved in
Kimchi by commit 50b104a46e65047dfdf299ff8a5f652f2422a949.
In addition, this patch depends on Wok's patch I sent a little bit early.
> Reasons:
> - other plugins will never be allowed to have a column named version in
> its table, for whatever reason they want;
It's false. Once a plugin is using Wok's ObjectStore structure, a column
version will be present starting on version 2.0.0. See commit
fec97768abc8b407d4eaaca2fc892708da7210c9
I see. I thought that version was tied to
Wok's version...
> - every new record must have the version inserted, today we cannot
> measure the impact, but, if for some reason objectstore must be heavily
> used, this can impact;
The complexity to record the version is the same of any other
information, since it's done once - when all information is recorded.
I was
talking about disk space and time to save/retrieve information.
> - we will have (or each plugin will have) to change this in future,
> because all 'object' tables will have 'version' column, then each
plugin
> will have to manage by itself how to check and update the records or
> schemas;
Kimchi already fixed this. Patches to Ginger and GingerBase was already
submitted to Ginger ML.
Thats why I said that works only for Kimchi/Ginger[Base]
...
WOK should be independent of plugin, what I see, is that wok is being
used to fix problems that the plugins should fix.
Actually, plugins will have to check the version of records in the future.
> - finally, I think that Wok should not touch plugins 'objectstore'.
>
Why not? It's a common infra-structure provided and that any plugin can
use. All current plugins (kimchi, ginger and gingerbase) that use
objectstore have a solution to this problem.
Bacause Wok is modifying what should be a private database.
Its ok Wok provides the infra (creates the db, provide functions to
add/remove/update, etc), it should not
touch the data.
> Like I said, this solution works for Kimchi/Ginger now, and I am
ok,
> once we are running out of time.
> But keep in mind , that we are going to have rework in future.
> Aline can decide what to do.
>
> Reviewed-by: Rodrigo Trujillo <rodrigo.trujillo(a)linux.vnet.ibm.com>
>
>
> On 12/14/2015 11:46 AM, pvital(a)linux.vnet.ibm.com wrote:
>> From: Paulo Vital <pvital(a)linux.vnet.ibm.com>
>>
>> This patch is part of the solution for the Ginger Issue #51 and it
>> depends on
>> Wok's "Upgrade objectstore schema" patch.
>>
>> With the new structure of the objectstore changed in Wok 2.0.0, the
>> schema of
>> the objectstore file needs to be checked and, if necessary, updated to
>> reflect
>> the new structure.
>>
>> This patch removes from Kimchi the methods used to check the
>> objectstore schema
>> and upgrade it if necessary. These methods are now present in
>> wok.plugins and
>> are common to any Wok plugin.
>>
>> Paulo Vital (1):
>> Update Kimchi objectstore versioning.
>>
>> root.py | 4 ++--
>> utils.py | 40 ----------------------------------------
>> 2 files changed, 2 insertions(+), 42 deletions(-)
>>
>> --
>> 2.5.0
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel