On 02/09/13 17:38, Dmitry Yemanov wrote: > All, > > Historically, we backup and restore security classes with names not > starting with 'SQL'. Regular security classes are SQL-based and they're > recreated at the commit (DFW) time, so there's really no sense in > transporting them back and forth. So I suppose that backup/restore > support is present for some kind of manually created security classes. > However, I failed to find such things in QLI, maybe it presented in GDEF > in the past days.
Even if present in QLI will not work in trunk - DYN support is broken, and they (isc_dyn_def_security_class) were done via it. > So, unless someone knows any good reason to see non-SQL security classes > in our databases, I'd suggest to remove security classes from backups > (avoid adding them to backup and skip them during restore). > > Rationale is simple: changes in ACLs are unlikely to be backward > compatible. If we bump ACL_version, the ACL transmitted from the newer > engine will throw a bugcheck in the older engine. If we don't bump > ACL_version, a bugcheck will be thrown anyway as soon as the older > engine notices a new ACL item. And, unlike similar situation with BLR, > new ACL item could appear (e.g. be created during restore) for the > existing metadata objects in the newer engine. So I suggest to treat > ACLs as a private part of the ODS and avoid migrating ACLs between > different FB versions, including backup/restore. > > Provided that ACLs *seem* to not being migrated now anyway, I don't > foresee any compatibility issues. But I could be missing something. > > Comments anyone? > Please kill that support - if you have not done it yet :-) ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
