[hibernate-dev] Data encoding change for Hibernate OGM / Infinispan Embedded
To fix the sequence generation consistency issue on Infinispan Embedded [OGM-1212] I will need to change how sequences are encoded within the datagrid. This means OGM 5.2 will be able to read data as encoded by previous versions, but it will write data using a new format. This has some implications, such as people upgrading temporarily to OGM 5.2 can't go back to previous versions (without restoring a backup of the data). I will document this limitation. There's a second aspect: OGM will now include some code to be able to read pre-5.1 data, but eventually we'll want to remote this. How should we handle that? I'm thinking that people hitting this problem (in some future) will simply need to fetch OGM 5.2 and use that as an intermediate step; however OGM will only upgrade the data encoding "lazily" as it goes along: when something happens to be read, and happens to be re-written, it will re-encode it. But some data might never be rolled over to the new format. So I think we'll eventually need a data migration tool which performs all data-encoding aspects eagerly, so that it can report a point in time for which it's done and safe to move on to a future version. I don't wish to create such a tool now for OGM version 5.2 but I we should agree on a plan already. I also wonder if this should mark the following issue "out of date": - https://hibernate.atlassian.net/browse/OGM-1148 Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JIRA usage for OGM
Yes labels and tags would help me to keep them "out of the way" but like Yoann suggests, I expect the "contrib repository" to not be released and tagged in strict synch with the Hibernate OGM main project? I guess we didn't discuss this in depth, but if we don't allow the "contrib repository" to fall slightly behind, we wouldn't have much of a benefit from cutting it into a separate repo.. Thanks, Sanne On 17 March 2017 at 11:34, Davide D'Alto wrote: > I would prefer to release both at the same time even if there are no > big changes. > > As for creating a new project, wouldn't have a new label or component be > enough? > > On Fri, Mar 17, 2017 at 8:21 AM, Yoann Rodiere wrote: >> Isn't marking those as "New feature" enough? Or, if necessary, tagging them? >> I obviously can't tell how others use JIRA, but personally I don't dive >> into old tickets every day. Most of the time I only check the new >> (incoming) tickets and those assigned to the next release. So, those extra >> tickets are only a problem when setting the goals for the next release, and >> we could easily tag them so as to exclude them from our searches. >> >> The actual question may be: when those tickets are solved, will they be >> released synchronously with OGM releases? I.e., will the contrib repository >> be released at the same time as OGM? If not, then yes, I'd say we'd better >> move these tickets to another JIRA project. >> >> >> Yoann Rodière >> Hibernate NoORM Team >> >> On 16 March 2017 at 14:14, Sanne Grinovero wrote: >> >>> There are more than 300 open issues, which is fine but rather than >>> being these well-defined issues most sound like wishful thinking of >>> someone having a (possibly cool) idea but not really executing on it. >>> >>> Since JIRA is an issue tracker and not really a planning tool / note >>> taking app I wish we could limit this practice of having issues like >>> "explore integration with.." ? >>> >>> More specifically, could we move "out of the way" all issues related >>> to Databases which we're moving into the "contrib" repository? >>> I think it would be nice to have these in a different JIRA project. >>> >>> Thanks, >>> Sanne >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JIRA usage for OGM
I would prefer to release both at the same time even if there are no big changes. As for creating a new project, wouldn't have a new label or component be enough? On Fri, Mar 17, 2017 at 8:21 AM, Yoann Rodiere wrote: > Isn't marking those as "New feature" enough? Or, if necessary, tagging them? > I obviously can't tell how others use JIRA, but personally I don't dive > into old tickets every day. Most of the time I only check the new > (incoming) tickets and those assigned to the next release. So, those extra > tickets are only a problem when setting the goals for the next release, and > we could easily tag them so as to exclude them from our searches. > > The actual question may be: when those tickets are solved, will they be > released synchronously with OGM releases? I.e., will the contrib repository > be released at the same time as OGM? If not, then yes, I'd say we'd better > move these tickets to another JIRA project. > > > Yoann Rodière > Hibernate NoORM Team > > On 16 March 2017 at 14:14, Sanne Grinovero wrote: > >> There are more than 300 open issues, which is fine but rather than >> being these well-defined issues most sound like wishful thinking of >> someone having a (possibly cool) idea but not really executing on it. >> >> Since JIRA is an issue tracker and not really a planning tool / note >> taking app I wish we could limit this practice of having issues like >> "explore integration with.." ? >> >> More specifically, could we move "out of the way" all issues related >> to Databases which we're moving into the "contrib" repository? >> I think it would be nice to have these in a different JIRA project. >> >> Thanks, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JIRA usage for OGM
Isn't marking those as "New feature" enough? Or, if necessary, tagging them? I obviously can't tell how others use JIRA, but personally I don't dive into old tickets every day. Most of the time I only check the new (incoming) tickets and those assigned to the next release. So, those extra tickets are only a problem when setting the goals for the next release, and we could easily tag them so as to exclude them from our searches. The actual question may be: when those tickets are solved, will they be released synchronously with OGM releases? I.e., will the contrib repository be released at the same time as OGM? If not, then yes, I'd say we'd better move these tickets to another JIRA project. Yoann Rodière Hibernate NoORM Team On 16 March 2017 at 14:14, Sanne Grinovero wrote: > There are more than 300 open issues, which is fine but rather than > being these well-defined issues most sound like wishful thinking of > someone having a (possibly cool) idea but not really executing on it. > > Since JIRA is an issue tracker and not really a planning tool / note > taking app I wish we could limit this practice of having issues like > "explore integration with.." ? > > More specifically, could we move "out of the way" all issues related > to Databases which we're moving into the "contrib" repository? > I think it would be nice to have these in a different JIRA project. > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
