Kern Sibbald wrote: > On Monday 12 June 2006 12:10, Jo wrote: > >> Kern Sibbald wrote: >> >>> Basing "consecutiveness" on MediaId will not work very well as the SQL >>> gurus can confirm since the MediaIds are not guaranteed to be >>> consecutive. In fact, if you ever delete any volumes, in most SQL >>> engines (e.g. like MySQL), the next volume created will take on the >>> lowest free MediaId. >>> >> I'm pretty sure that the normal way of working for an SQL engine is to >> always use a higher number when creating new records. That's how the >> serial type in PostgreSQL works. I don't think an RDBMS tries to >> 'recycle' primary keys. This might have very nasty side effects when >> there would still be some foreign keys point to that primary key. Of >> course, I don't know if this MediaID is in fact a primary key. >> > > Using the next higher key number may be how PostgreSQL does it, but I would > hesitate to call this "the normal way of working" since there are probably > many more MySQL installations, and I can assure you that MySQL has no problem > reassigning a previously used ID at least when using the MyISAM indexes as I > am. > > In any case, what is "normal" is not very important. What counts is that you > can never be 100% sure how the ID will be assigned since it is up to the DB > to decide, and to the best of my knowledge there is no external standard that > requires anything one way or another. > Hi Kern,
You are right, it's not a good idea to base a decision on something Bacula doesn't have control over. A DB could come up with a number at random, check if it has not been used yet and use that, but usually it's more efficient to go through them sequentially. Kind regards, Jo _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
