CCing spacewalk-devel.
Pradeep Kilambi wrote:
Miroslav Suchý wrote:
Prad,
why did you make desighn changes to tables. Starting from commit
2961816197ba1417eb6ffaa485ae4ddf1f4f4a37
Resulting table is not even normal form #1.
I'm strongly against this change.
Hey Mirek, So here is why,
We have to make our design compatible with hosted. Now the way we store
the checksum in the db is for an entire rpm and not jus the header. So
the problem with our initial design is that, we should be getting that
checksum info from somewhere in the rpm but that would only be header +
payload, but this will not work as if we want to make our design
compatible with hosted. The model should be able to have N different
checksums associated with a single piece of content at once. We'd want
this in hosted to be able to export the RHEL 6 channel to a satellite
that doesn't have support for sha256, or to have a single piece of
content stored only once on the filer and the db for both rhel 5 and
rhel 6.
I still did not see this as reason. How hosted internals affect our db
schema? See my proposal on bottom, to see that we can have N different
checksum associated with a single piece of content.
So I had two proposals, one was to have a separate table the way we had
before rhnPackageChecksum and this will have all the checksum info. But
then we'll have a problem with nevra feature, so we cannot remove the
md5sum from rhnPackage table as thats the column we base our uniqueness
on along with others. Hence decided the sane approach is to have an
extra column and we compute both sha256 and md5sum in the db per
package. Now wrt to scalability, I understand if we have another
chechsum to support tomorrow, we have to add another column. But moving
md5sum to another table is a big change for UI and app. So talking to
our java guys around, they really dint want us to move md5sum out of
rhnPackage table. So hence the change.
Yes, that can be reason. But ...
Let separate two things. The md5sum we use internally from md5sum we
give to older clients. We can leave columnt md5sum as is. And use it for
internal stuff (store to /var/satellite etc.) - Let rename your table
rhnPackageChecksum to rhnChecksum - And have table rhnPackageChecksum
with columns packageid (FK to rhnPackage), checksumtype (FK to
rhnChecksum), checksum. With primary key (packageid, checksumtype).
For this time we can create trigger on rhnPackage and rhnPackageChecksum
which will enforce consistency of md5sum column and checksum of type
'md5' from rhnPackageChecksum.
This way all internals, which depend on md5, can be leaved untouched.
And we can happy work on SHA256.
Column md5sum will become obsolete and we can slowly (sometimes in
future) edit all code which use it. And when the time come we can delete.
Was gonna talk to you guys once we sorted the db changes with michael,
but email dialog is fine too.
lemme know if this helps your concern, and why you feel against it.
--
Miroslav Suchy
Red Hat Satellite Engineering
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
