From: Vlad H. <hv...@us...> - 2007-05-30 15:19:00
|
> Vlad Horsun wrote: > > All, > > > > I think we must have working solution _before_ beta > > > Yes. Very well ;) > >>> Anyway if engine can handle blobs automatically then it must do it, is not is ? > >>> > >> I'm not sure about your proposal. > >> > > > > What problem do you see ? > > > I see it doesn't addresses the problem completely, and then I prefer a > script instead of introduce a thing that doesn't work in all cases. It adressed problem with blob's. No more, no less. And i think 99% of problem is blobs. I didn't said we don't need the script. I just want to not run it in most cases ;) > You said to not allow new malformed data, but allow restore of it. In blobs. We can't implement the same trick for [VAR]CHAR's, unfortunately > If you restore a UNICODE_FSS [VAR]CHAR field and try to assign it to a > blob later, your blob will receive malformed data. And engine will throw error. And this is good, imo > A possible solution for this problem may be to play with record formats > and restore legacy UNICODE_FSS fields as NONE and create a new format > after the data. Don't know if this will work. It will convert fields to new format on reading and thus transliterate data from NONE to UNICODE_FSS without guarantee it is possible > > Look at 'blob problem' from more formal point of view. We introduced new blob > > attribute - charset (it stored on disk within blob record header). > Ok. > > > This allows to have blob instance charset be different from column type charset. > It's not the intention, but could be used in the future when we allow > change blob charset (ALTER ... TYPE BLOB ... CHARACTER SET ...) Yes > > It force us to save this information in backup and restore it from backup properly, is not is ? > > > No. The charset is not saved in backups. But must be saved, imo. > The field was added to blob header because when one need to read a blob, > he pass the blob id to the engine, and the engine don't know for what > field (and charset) this blob is. > > Saving the charset in ODS allows the engine to perform automatic > transliteration. Yes, i know ;) > We don't need to save in backup because when restoring a backup, blobs > will be created again using the newest table format. Its wrong as we don't know character set of blob data in backup. > If you want different blob charsets, again, I think you should play with > formats instead of save the charset in backups. No, please ;) > > PS I can implement proposed solution if you have no time for it > My plans was to in FB3, never allow malformed data. > People will need to fix the metadata and data before restore in it. We already made life of peoples harder with every new release ;) If we can avoid some complication, we must avoid it, imo. > You're saying to do this verification (only for new data) now (in beta > phase). _I_ saying to _do_ verification ? Sorry, you confuse me with someone else ;) > This is one thing which was intentionally not done in FB2. > > If you implement this, be sure I'll try the most as I can to introduce > malformed data in blobs of ODS11 ;-), and if the engine allows it, I > think the fix is not good. The engine will assign charset NONE for blob data restored from old backups. Also it will save in new backup blob's charset and assign this charset back to blob when restoring this backup. So, if user will not touch blob contents after restore with FB 2.1 we'll have this blob with charset NONE in all next FB versions. Ah, forgot to say, engine will not transliterate such blobs on reading. Regards, Vlad |