Hi!
On Aug 29, mohsen ali momeni wrote:
> Hello Mr. Golubchik
>
> I have some problems and need your help.
>
> To save calendar in frm files, I used offset 17 of buff in pack_fields
> function but there was some problems which terminated the mysql server
> abnormaly.
Yes, unfortunately. frm format is fixed, it's not easy to add bytes to
it, that's why we want to migrate to a new more flexible format.
> I don't know which offset I should use.(maybe I should wait for new
> version of mysql as you said frm files will have more space, now I
> work on last stable version) For test, I saved calendar as a unsigned
> char instead of charset number in offset 14 and it worked with no
> problem.
Yes, it's ok - after all a field cannot have a charset and calendar at
the same time, it's either a date field (has calendar, but not a
charset) or a string (has charset, but not a calendar).
Good idea.
> Also calendar and date values are saved correctly in fields. Selection
> and insertion are handled with no obvious problem.
> Now I am working on Date functions and operators (like <) to make them
> work for different calendars.
Great!
> Another problem is the Field_newdate class which is a replacement for
> Field_date, the problem is that it stores date values as 3 bytes.
> There is no space to save a 8 bit calendar value (for 31 calendars).
But why do you want to do it ? Saving calendar in the date value, means
that you can store in one column dates from different calendars, that is
store a gregorian date, a jalali date, etc. and they are retrieved in
the their calendars.
I think it's a little bit of overkill, and it's enough to have a
calendar fixed per column - that is a column can only store dates of one
particular calendar. Then you don't need to store the calendar in the
date value, it's enough to store it in the field's definition in the
frm file - in that byte with offset 14.
> For now, I save calendar with the assumption that year value is a
> small number around 2000.
> Till now, there was no need to embede the calendar in date values and
> I don't think it will be even needed for comparison like dt<=dtj; I
> think it's better to convert all Dates to GREGORIAN before comparison
> if they are not from the same calendar, as the comparison is in binary
> string form.
Ok, if it'll be enough, so the better :)
> I don't know if we really need to embede calendar in date values?
> Maybe I ignore some cases which we really need calendar embedding.
I *thought* it will be necessary when comparing dates as strings,
because looking at the string one does not know what calendar the dates
belongs to. But I may be wrong and if you have enough metadata to know
the calendar, then embedding is not necessary, of course.
Regards,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Kerpen, Germany
<___/ www.mysql.com
