prefixMap refactoring

[Kamen Mazdrashki]

Hi Metze,

On Wed, Oct 7, 2009 at 18:22, Stefan (metze) Metzmacher <metze at samba.org> wrote:
>
> I'm mostly happy with the patches, there're are some minor things in
> the 0006-... patch, I'll try to comment on them in detail tomorrow.

Please note that I am considering this patch as an intermediate one.
After moving prefixMap implementation into separate file (module),
most of changes in schema_init.c should become obsolete.

>
> One thing we should think about is that this won't work with existing
> installations are the on-disk format of the prefixMap attribute has
> changed... Do we care about that? (We'll have a lot of other changes to
> do, which will also break the on-disk format, so I guess it's fine, but
> I want other's to comment on this)
>
You almost got me convinced there is a backward compatibility problem 
here. And I was just about to propose 2 ways to fix this :)
But after some thinking, it turns out there should be no backward
compatibility issue.
Please correct me if I am utterly wrong but:
- prefixMap is stored in its binary form in DS database right?
- new changes deals with binary format of prefixMap just fine, so
  there should be no problems and prefixMapBlob structure should be
  decoded in the same way as it is happening when receiving data 
  on the wire. 


However, here is what I was thinking about solving such 
backward compatibility issues in DS database (for sure we will need
some mechanism to resolve such issues in near future):
I was thinking about a "migration utility". 
We can store current
DS database internal version code somewhere.
When an internal data or data structure is to be changed for the 
next Samba4 release, whoever made that change should implement a 
"migration function" to be linked in "migration utility" which 
is to execute this function when database migration happens 
(presumably when someone upgrades Samba4 to a later version).
For example:
in Version 100 of DS database we have ReplicaOID stored as:
  struct ReplicaOID {
    int a;
    int b;
  }
In some release afterward, I decide to redefine this structure as:
  struct ReplicaOID {
    int a;
    int b;
    int c;
  }
In this case, I should bump DS database version to 101 and 
implement "DS_migrate_100_to_101" function in which to call
a function, to read ReplicaOID_100 and write it as
ReplicaOID_101.

Very simple example I know, just wanted to illustrate what I am
talking about :)




BR,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/