From vitor.lima at eldorado.org.br Tue Aug 27 11:46:27 2013 Content-Type: multipart/mixed; boundary="===============8958751035761291053==" MIME-Version: 1.0 From: Vitor de Lima To: devel at ovirt.org Subject: [Engine-devel] Questions about database changes Date: Tue, 27 Aug 2013 13:18:12 +0000 Message-ID: --===============8958751035761291053== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --_000_B2CAFC4D5E2D574A883EF61ACD5ADE3301810A60SERV070corpeldo_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, I would like some feedback about how to create the upgrade script that crea= =3D tes columns for the architecture of each VM, template and cluster in the en= =3D gine database. The changes #17853 and #16700 introduce a field (and the respective Enum) u= =3D sed to store the target architecture of a cluster, VM or template (which cu= =3D rrently can be either x86_64, ppc64 or undefined). In their current state, these changes introduce a VARCHAR column storing th= =3D e architecture, but now I wanted to implement an autocompleter for this fie= =3D ld in the search backend, and it would be massively cleaner and easier to u= =3D se the architecture field as an integer (since Enums that implement the Ide= =3D ntifiable interface can use the EnumValueAutoCompleter class). Considering that these two changes are already in review, should I modify t= =3D hem directly to use an integer or should I create another patch that change= =3D s the column in the database? If I create another patch, should it modify t= =3D he upgrade script from change #16700 or it must create another script that = =3D migrates the column from a VARCHAR to an INTEGER? Thanks, Vitor de Lima --_000_B2CAFC4D5E2D574A883EF61ACD5ADE3301810A60SERV070corpeldo_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,<=3D /p>

I would like some feedback = abou=3D t how to create the upgrade script that creates columns for the architectur= =3D e of each VM, template and cluster in the engine database.

The changes #17853 and #167= 00 i=3D ntroduce a field (and the respective Enum) used to store the target archite= =3D cture of a cluster, VM or template (which currently can be either x86_64, p= =3D pc64 or undefined).

In their current state, the= se c=3D hanges introduce a VARCHAR column storing the architecture, but now I wante= =3D d to implement an autocompleter for this field in the search backend, and i= =3D t would be massively cleaner and easier to use the architecture field as an integer (since Enums that implement th= =3D e Identifiable interface can use the EnumValueAutoCompleter class).

Considering that these two = chan=3D ges are already in review, should I modify them directly to use an integer = =3D or should I create another patch that changes the column in the database? I= =3D f I create another patch, should it modify the upgrade script from change #16700 or it must create another scr= =3D ipt that migrates the column from a VARCHAR to an INTEGER?

Thanks,

Vitor de Lima

--_000_B2CAFC4D5E2D574A883EF61ACD5ADE3301810A60SERV070corpeldo_-- --===============8958751035761291053== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1fMDAwX0IyQ0FGQzRENUUyRDU3NEE4ODNFRjYxQUNENUFERTMzMDE4MTBBNjBTRVJWMDcwY29y cGVsZG9fCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUKCkhpIGV2ZXJ5b25lLAoKSSB3 b3VsZCBsaWtlIHNvbWUgZmVlZGJhY2sgYWJvdXQgaG93IHRvIGNyZWF0ZSB0aGUgdXBncmFkZSBz Y3JpcHQgdGhhdCBjcmVhPQp0ZXMgY29sdW1ucyBmb3IgdGhlIGFyY2hpdGVjdHVyZSBvZiBlYWNo IFZNLCB0ZW1wbGF0ZSBhbmQgY2x1c3RlciBpbiB0aGUgZW49CmdpbmUgZGF0YWJhc2UuCgpUaGUg Y2hhbmdlcyAjMTc4NTMgYW5kICMxNjcwMCBpbnRyb2R1Y2UgYSBmaWVsZCAoYW5kIHRoZSByZXNw ZWN0aXZlIEVudW0pIHU9CnNlZCB0byBzdG9yZSB0aGUgdGFyZ2V0IGFyY2hpdGVjdHVyZSBvZiBh IGNsdXN0ZXIsIFZNIG9yIHRlbXBsYXRlICh3aGljaCBjdT0KcnJlbnRseSBjYW4gYmUgZWl0aGVy IHg4Nl82NCwgcHBjNjQgb3IgdW5kZWZpbmVkKS4KSW4gdGhlaXIgY3VycmVudCBzdGF0ZSwgdGhl c2UgY2hhbmdlcyBpbnRyb2R1Y2UgYSBWQVJDSEFSIGNvbHVtbiBzdG9yaW5nIHRoPQplIGFyY2hp dGVjdHVyZSwgYnV0IG5vdyBJIHdhbnRlZCB0byBpbXBsZW1lbnQgYW4gYXV0b2NvbXBsZXRlciBm b3IgdGhpcyBmaWU9CmxkIGluIHRoZSBzZWFyY2ggYmFja2VuZCwgYW5kIGl0IHdvdWxkIGJlIG1h c3NpdmVseSBjbGVhbmVyIGFuZCBlYXNpZXIgdG8gdT0Kc2UgdGhlIGFyY2hpdGVjdHVyZSBmaWVs ZCBhcyBhbiBpbnRlZ2VyIChzaW5jZSBFbnVtcyB0aGF0IGltcGxlbWVudCB0aGUgSWRlPQpudGlm aWFibGUgaW50ZXJmYWNlIGNhbiB1c2UgdGhlIEVudW1WYWx1ZUF1dG9Db21wbGV0ZXIgY2xhc3Mp LgoKQ29uc2lkZXJpbmcgdGhhdCB0aGVzZSB0d28gY2hhbmdlcyBhcmUgYWxyZWFkeSBpbiByZXZp ZXcsIHNob3VsZCBJIG1vZGlmeSB0PQpoZW0gZGlyZWN0bHkgdG8gdXNlIGFuIGludGVnZXIgb3Ig c2hvdWxkIEkgY3JlYXRlIGFub3RoZXIgcGF0Y2ggdGhhdCBjaGFuZ2U9CnMgdGhlIGNvbHVtbiBp biB0aGUgZGF0YWJhc2U/IElmIEkgY3JlYXRlIGFub3RoZXIgcGF0Y2gsIHNob3VsZCBpdCBtb2Rp ZnkgdD0KaGUgdXBncmFkZSBzY3JpcHQgZnJvbSBjaGFuZ2UgIzE2NzAwIG9yIGl0IG11c3QgY3Jl YXRlIGFub3RoZXIgc2NyaXB0IHRoYXQgPQptaWdyYXRlcyB0aGUgY29sdW1uIGZyb20gYSBWQVJD SEFSIHRvIGFuIElOVEVHRVI/CgpUaGFua3MsClZpdG9yIGRlIExpbWEKCgotLV8wMDBfQjJDQUZD NEQ1RTJENTc0QTg4M0VGNjFBQ0Q1QURFMzMwMTgxMEE2MFNFUlYwNzBjb3JwZWxkb18KQ29udGVu dC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9InVzLWFzY2lpIgpDb250ZW50LVRyYW5zZmVyLUVu Y29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbCB4bWxuczp2PTNEInVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206dm1sIiB4bWxuczpvPTNEInVybjpzY2hlbWFzLW1pY3I9Cm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIiB4bWxuczp3PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiID0KeG1sbnM6bT0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8y MDA0LzEyL29tbWwiIHhtbG5zPTNEImh0dHA6PQovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+ CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PTNEIkNvbnRlbnQtVHlwZSIgY29udGVudD0zRCJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9M0R1cy1hc2NpaSI9Cj4KPG1ldGEgbmFtZT0zRCJHZW5lcmF0b3IiIGNv bnRlbnQ9M0QiTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJp OwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAq LwpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBjbTsK CW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMS4wcHQ7Cglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1 ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5FbWFpbFN0eWxlMTcKCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1jb21wb3NlOwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsK CWNvbG9yOndpbmRvd3RleHQ7fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7CgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtO30KZGl2LldvcmRTZWN0aW9u MQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0zRCJlZGl0IiBzcGlkbWF4PTNEIjEwMjYiIC8+Cjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91dCB2 OmV4dD0zRCJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9M0QiZWRpdCIgZGF0YT0zRCIxIiAvPgo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFuZz0zRCJQVC1C UiIgbGluaz0zRCJibHVlIiB2bGluaz0zRCJwdXJwbGUiPgo8ZGl2IGNsYXNzPTNEIldvcmRTZWN0 aW9uMSI+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PHNwYW4gbGFuZz0zRCJFTi1VUyI+SGkgZXZl cnlvbmUsPG86cD48L286cD48L3NwYW4+PD0KL3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PHNw YW4gbGFuZz0zRCJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0z RCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPkkgd291bGQgbGlrZSBzb21lIGZlZWRi YWNrIGFib3U9CnQgaG93IHRvIGNyZWF0ZSB0aGUgdXBncmFkZSBzY3JpcHQgdGhhdCBjcmVhdGVz IGNvbHVtbnMgZm9yIHRoZSBhcmNoaXRlY3R1cj0KZSBvZiBlYWNoIFZNLCB0ZW1wbGF0ZSBhbmQg Y2x1c3RlciBpbiB0aGUgZW5naW5lIGRhdGFiYXNlLjxvOnA+PC9vOnA+PC9zcGFuPQo+PC9wPgo8 cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVOLVVT Ij5UaGUgY2hhbmdlcyAjMTc4NTMgYW5kICMxNjcwMCBpPQpudHJvZHVjZSBhIGZpZWxkIChhbmQg dGhlIHJlc3BlY3RpdmUgRW51bSkgdXNlZCB0byBzdG9yZSB0aGUgdGFyZ2V0IGFyY2hpdGU9CmN0 dXJlIG9mIGEgY2x1c3RlciwgVk0gb3IgdGVtcGxhdGUgKHdoaWNoIGN1cnJlbnRseSBjYW4gYmUg ZWl0aGVyIHg4Nl82NCwgcD0KcGM2NCBvciB1bmRlZmluZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVOLVVTIj5JbiB0aGVpciBj dXJyZW50IHN0YXRlLCB0aGVzZSBjPQpoYW5nZXMgaW50cm9kdWNlIGEgVkFSQ0hBUiBjb2x1bW4g c3RvcmluZyB0aGUgYXJjaGl0ZWN0dXJlLCBidXQgbm93IEkgd2FudGU9CmQgdG8gaW1wbGVtZW50 IGFuIGF1dG9jb21wbGV0ZXIgZm9yIHRoaXMgZmllbGQgaW4gdGhlIHNlYXJjaCBiYWNrZW5kLCBh bmQgaT0KdCB3b3VsZCBiZSBtYXNzaXZlbHkgY2xlYW5lciBhbmQgZWFzaWVyCiB0byB1c2UgdGhl IGFyY2hpdGVjdHVyZSBmaWVsZCBhcyBhbiBpbnRlZ2VyIChzaW5jZSBFbnVtcyB0aGF0IGltcGxl bWVudCB0aD0KZSBJZGVudGlmaWFibGUgaW50ZXJmYWNlIGNhbiB1c2UgdGhlIEVudW1WYWx1ZUF1 dG9Db21wbGV0ZXIgY2xhc3MpLjxvOnA+PC9vPQo6cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0zRCJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVOLVVTIj5Db25zaWRlcmlu ZyB0aGF0IHRoZXNlIHR3byBjaGFuPQpnZXMgYXJlIGFscmVhZHkgaW4gcmV2aWV3LCBzaG91bGQg SSBtb2RpZnkgdGhlbSBkaXJlY3RseSB0byB1c2UgYW4gaW50ZWdlciA9Cm9yIHNob3VsZCBJIGNy ZWF0ZSBhbm90aGVyIHBhdGNoIHRoYXQgY2hhbmdlcyB0aGUgY29sdW1uIGluIHRoZSBkYXRhYmFz ZT8gST0KZiBJIGNyZWF0ZSBhbm90aGVyIHBhdGNoLCBzaG91bGQgaXQKIG1vZGlmeSB0aGUgdXBn cmFkZSBzY3JpcHQgZnJvbSBjaGFuZ2UgIzE2NzAwIG9yIGl0IG11c3QgY3JlYXRlIGFub3RoZXIg c2NyPQppcHQgdGhhdCBtaWdyYXRlcyB0aGUgY29sdW1uIGZyb20gYSBWQVJDSEFSIHRvIGFuIElO VEVHRVI/PG86cD48L286cD48L3NwYW49Cj48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PHNw YW4gbGFuZz0zRCJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0z RCJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFs Ij5WaXRvciBkZSBMaW1hPG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4KCi0tXzAwMF9CMkNBRkM0 RDVFMkQ1NzRBODgzRUY2MUFDRDVBREUzMzAxODEwQTYwU0VSVjA3MGNvcnBlbGRvXy0tCg== --===============8958751035761291053==-- From yzaslavs at redhat.com Wed Aug 28 02:56:30 2013 Content-Type: multipart/mixed; boundary="===============7102940187924662263==" MIME-Version: 1.0 From: Yair Zaslavsky To: devel at ovirt.org Subject: Re: [Engine-devel] Questions about database changes Date: Wed, 28 Aug 2013 02:56:26 -0400 Message-ID: <280797646.4816097.1377672986447.JavaMail.root@redhat.com> In-Reply-To: B2CAFC4D5E2D574A883EF61ACD5ADE3301810A60@SERV070.corp.eldorado.org.br --===============7102940187924662263== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Vitor de Lima" > To: engine-devel(a)ovirt.org > Sent: Tuesday, August 27, 2013 4:18:12 PM > Subject: [Engine-devel] Questions about database changes > = > Hi everyone, > = > I would like some feedback about how to create the upgrade script that > creates columns for the architecture of each VM, template and cluster in = the > engine database. > = > The changes #17853 and #16700 introduce a field (and the respective Enum) > used to store the target architecture of a cluster, VM or template (which > currently can be either x86_64, ppc64 or undefined). > In their current state, these changes introduce a VARCHAR column storing = the > architecture, but now I wanted to implement an autocompleter for this fie= ld > in the search backend, and it would be massively cleaner and easier to use > the architecture field as an integer (since Enums that implement the > Identifiable interface can use the EnumValueAutoCompleter class). > = > Considering that these two changes are already in review, should I modify > them directly to use an integer or should I create another patch that > changes the column in the database? If I create another patch, should it > modify the upgrade script from change #16700 or it must create another > script that migrates the column from a VARCHAR to an INTEGER? > = > Thanks, > Vitor de Lima If still under review, why not modify the existing patches for review? (i.e= - use the same change-id where needed) Cheers, Yair > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============7102940187924662263==-- From lhornyak at redhat.com Wed Aug 28 03:04:45 2013 Content-Type: multipart/mixed; boundary="===============0211325400165200710==" MIME-Version: 1.0 From: Laszlo Hornyak To: devel at ovirt.org Subject: Re: [Engine-devel] Questions about database changes Date: Wed, 28 Aug 2013 03:04:36 -0400 Message-ID: <2061536701.6327409.1377673476006.JavaMail.root@redhat.com> In-Reply-To: 280797646.4816097.1377672986447.JavaMail.root@redhat.com --===============0211325400165200710== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Vitor, Just one more note, use an int stored in the enum and ignore the ordinal wh= en storing/reading from the DB, so when adding new members and re-ordering = the enum, the DB will still be ok. ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Vitor de Lima" > Cc: engine-devel(a)ovirt.org > Sent: Wednesday, August 28, 2013 8:56:26 AM > Subject: Re: [Engine-devel] Questions about database changes > = > = > = > ----- Original Message ----- > > From: "Vitor de Lima" > > To: engine-devel(a)ovirt.org > > Sent: Tuesday, August 27, 2013 4:18:12 PM > > Subject: [Engine-devel] Questions about database changes > > = > > Hi everyone, > > = > > I would like some feedback about how to create the upgrade script that > > creates columns for the architecture of each VM, template and cluster in > > the > > engine database. > > = > > The changes #17853 and #16700 introduce a field (and the respective Enu= m) > > used to store the target architecture of a cluster, VM or template (whi= ch > > currently can be either x86_64, ppc64 or undefined). > > In their current state, these changes introduce a VARCHAR column storing > > the > > architecture, but now I wanted to implement an autocompleter for this f= ield > > in the search backend, and it would be massively cleaner and easier to = use > > the architecture field as an integer (since Enums that implement the > > Identifiable interface can use the EnumValueAutoCompleter class). > > = > > Considering that these two changes are already in review, should I modi= fy > > them directly to use an integer or should I create another patch that > > changes the column in the database? If I create another patch, should it > > modify the upgrade script from change #16700 or it must create another > > script that migrates the column from a VARCHAR to an INTEGER? > > = > > Thanks, > > Vitor de Lima > = > If still under review, why not modify the existing patches for review? (i= .e - > use the same change-id where needed) > = > Cheers, > Yair > = > > = > > = > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============0211325400165200710==-- From emesika at redhat.com Wed Aug 28 16:14:30 2013 Content-Type: multipart/mixed; boundary="===============4325917147367114135==" MIME-Version: 1.0 From: Eli Mesika To: devel at ovirt.org Subject: Re: [Engine-devel] Questions about database changes Date: Wed, 28 Aug 2013 16:14:21 -0400 Message-ID: <2077345788.5926220.1377720861671.JavaMail.root@redhat.com> In-Reply-To: 280797646.4816097.1377672986447.JavaMail.root@redhat.com --===============4325917147367114135== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Vitor de Lima" > Cc: engine-devel(a)ovirt.org > Sent: Wednesday, August 28, 2013 9:56:26 AM > Subject: Re: [Engine-devel] Questions about database changes > = > = > = > ----- Original Message ----- > > From: "Vitor de Lima" > > To: engine-devel(a)ovirt.org > > Sent: Tuesday, August 27, 2013 4:18:12 PM > > Subject: [Engine-devel] Questions about database changes > > = > > Hi everyone, > > = > > I would like some feedback about how to create the upgrade script that > > creates columns for the architecture of each VM, template and cluster in > > the > > engine database. > > = > > The changes #17853 and #16700 introduce a field (and the respective Enu= m) > > used to store the target architecture of a cluster, VM or template (whi= ch > > currently can be either x86_64, ppc64 or undefined). > > In their current state, these changes introduce a VARCHAR column storing > > the > > architecture, but now I wanted to implement an autocompleter for this f= ield > > in the search backend, and it would be massively cleaner and easier to = use > > the architecture field as an integer (since Enums that implement the > > Identifiable interface can use the EnumValueAutoCompleter class). > > = > > Considering that these two changes are already in review, should I modi= fy > > them directly to use an integer or should I create another patch that > > changes the column in the database? If I create another patch, should it > > modify the upgrade script from change #16700 or it must create another > > script that migrates the column from a VARCHAR to an INTEGER? > > = > > Thanks, > > Vitor de Lima > = > If still under review, why not modify the existing patches for review? (i= .e - > use the same change-id where needed) I agree , patches are not merged yet , so change should be in original upgr= ade it will not affect anyone except of the specific developer that tested = that.... > = > Cheers, > Yair > = > > = > > = > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============4325917147367114135==--