Hi,
What is the purpose of the "SQL definitions" settings found in kamctlrc? It is also stated that one should edit db/schema/entities.xml but I can't seem to find this file.
kamctlrc contains:
# SQL definitions # If you change this definitions here, then you must change them # in db/schema/entities.xml too. # FIXME
# FOREVER="2020-05-28 21:32:15" # DEFAULT_ALIASES_EXPIRES=$FOREVER # DEFAULT_Q="1.0" # DEFAULT_CALLID="Default-Call-ID" # DEFAULT_CSEQ="13" # DEFAULT_LOCATION_EXPIRES=$FOREVER
Thanks,
Vieri
Am Sonntag, 2. September 2012, 12:41:43 schrieb Vieri:
What is the purpose of the "SQL definitions" settings found in kamctlrc? It is also stated that one should edit db/schema/entities.xml but I can't seem to find this file.
kamctlrc contains:
# SQL definitions # If you change this definitions here, then you must change them # in db/schema/entities.xml too. # FIXME
# FOREVER="2020-05-28 21:32:15" [..]
Hello Vieri,
this definitions just needs to be the same as in the database scheme, as they are used in the script. The path was indeed outdated, I've just fixed it in git master.
Cheers,
Henning
--- On Mon, 9/3/12, Henning Westerholt hw@kamailio.org wrote:
kamctlrc contains:
# SQL definitions # If you change this definitions here, then you must
change them
# in db/schema/entities.xml too. # FIXME
# FOREVER="2020-05-28 21:32:15" [..]
Hello Vieri,
this definitions just needs to be the same as in the database scheme, as they are used in the script. The path was indeed outdated, I've just fixed it in git master.
Thanks Henning.
Why is the default FOREVER="2020-05-28 21:32:15"? I suppose it's just the way the original dev set it up. Could the package default be something more like the following? FOREVER="9999-01-01 00:00:00"
Thanks,
Vieri
Am Mittwoch, 5. September 2012, 14:06:14 schrieb Vieri:
# FOREVER="2020-05-28 21:32:15" [..]
this definitions just needs to be the same as in the database scheme, as they are used in the script. The path was indeed outdated, I've just fixed it in git master.
Why is the default FOREVER="2020-05-28 21:32:15"? I suppose it's just the way the original dev set it up. Could the package default be something more like the following? FOREVER="9999-01-01 00:00:00"
Hello Vieri,
well, there is the issue that this is then wrongly parsed from some databases, also depending on the exact type which is used. In mysql it supports in some types a date like this, in some types only to the year 2038.
But you're right in bringing this issue up. I'd suggest to update it to "2030-05-28 21:32:15" or something like this.
Cheers,
Henning Westerholt
Am Mittwoch, 5. September 2012, 14:11:34 schrieb Henning Westerholt:
# FOREVER="2020-05-28 21:32:15" [..]
this definitions just needs to be the same as in the database scheme, as they are used in the script. The path was indeed outdated, I've just fixed it in git master.
Why is the default FOREVER="2020-05-28 21:32:15"? I suppose it's just the way the original dev set it up. Could the package default be something more like the following? FOREVER="9999-01-01 00:00:00"
well, there is the issue that this is then wrongly parsed from some databases, also depending on the exact type which is used. In mysql it supports in some types a date like this, in some types only to the year 2038.
But you're right in bringing this issue up. I'd suggest to update it to "2030-05-28 21:32:15" or something like this.
Hello Vieri,
I've commited a change to git repository to move the expire time 10 years to the future - to have a bit more time here.
Cheers,
Henning
--- On Fri, 9/7/12, Henning Westerholt hw@kamailio.org wrote:
I've commited a change to git repository to move the expire time 10 years to the future - to have a bit more time here.
Thanks Henning
-
Henning Westerholt -
Vieri