asterisk

Author SHA1 Message Date

Author	SHA1	Message	Date
George Joseph	751d7a5a49	alembic: Remove batch operations (and sqlite support) Because SQLite doesn't support full ALTER capabilities, alembic scripts require batch operations. However, that capability wasn't available until 0.7.0 which some distributions haven't reached yet. Therefore, the batch operations introduced in commit `86d6e44cc` (review 2319) have been reverted and SQLite is unsupported again, for now anyway. Tested the full upgrade and downgrade on MySQL/Mariadb and Postgresql. ASTERISK-25890 #close Reported-by: Harley Peters Change-Id: I82eba5456736320256f6775f5b0b40133f4d1c80	10 years ago
George Joseph	b8b7c2e428	alembic: Fix downgrade and tweak for sqlite Downgrade had a few issues. First there was an errant 'update' statement in add_auto_dtmf_mode that looks like it was a copy/paste error. Second, we weren't cleaning up the ENUMs so subsequent upgrades on postgres failed because the types already existed. For sqlite... sqlite doesn't support ALTER or DROP COLUMN directly. Fortunately alembic batch_operations takes care of this for us if we use it so the alter and drops were converted to use batch operations. Here's an example downgrade: with op.batch_alter_table('ps_endpoints') as batch_op: batch_op.drop_column('tos_audio') batch_op.drop_column('tos_video') batch_op.add_column(sa.Column('tos_audio', yesno_values)) batch_op.add_column(sa.Column('tos_video', yesno_values)) batch_op.drop_column('cos_audio') batch_op.drop_column('cos_video') batch_op.add_column(sa.Column('cos_audio', yesno_values)) batch_op.add_column(sa.Column('cos_video', yesno_values)) with op.batch_alter_table('ps_transports') as batch_op: batch_op.drop_column('tos') batch_op.add_column(sa.Column('tos', yesno_values)) # Can't cast integers to YESNO_VALUES, so dropping and adding is required batch_op.drop_column('cos') batch_op.add_column(sa.Column('cos', yesno_values)) Upgrades from base to head and downgrades from head to base were tested repeatedly for postgresql, mysql/mariadb, and sqlite3. Change-Id: I862b0739eb3fd45ec3412dcc13c2340e1b7baef8	10 years ago
Kevin Harwell	691c0e0b31	res_pjsip_outbound_registration: registration stops due to fatal 4xx response During outbound registration it is possible to receive a fatal (any permanent/ non-temporary 4xx, 5xx, 6xx) response from the registrar that is simply due to a problem with the registrar itself. Upon receiving the failure response Asterisk terminates outbound registration for the given endpoint. This patch adds an option, 'fatal_retry_interval', that when set continues outbound registration at the given interval up to 'max_retries' upon receiving a fatal response. ASTERISK-25485 #close Change-Id: Ibc2c7b47164ac89cc803433c0bbe7063bfa143a2	10 years ago

George Joseph

alembic: Remove batch operations (and sqlite support)

Because SQLite doesn't support full ALTER capabilities, alembic scripts
require batch operations.  However, that capability wasn't available until
0.7.0 which some distributions haven't reached yet.  Therefore, the batch
operations introduced in commit 86d6e44cc (review 2319) have been reverted
and SQLite is unsupported again, for now anyway.

Tested the full upgrade and downgrade on MySQL/Mariadb and Postgresql.

ASTERISK-25890 #close
Reported-by: Harley Peters

Change-Id: I82eba5456736320256f6775f5b0b40133f4d1c80

George Joseph

b8b7c2e428

alembic: Fix downgrade and tweak for sqlite

Downgrade had a few issues.  First there was an errant 'update' statement in
add_auto_dtmf_mode that looks like it was a copy/paste error.  Second, we
weren't cleaning up the ENUMs so subsequent upgrades on postgres failed
because the types already existed.

For sqlite...  sqlite doesn't support ALTER or DROP COLUMN directly.
Fortunately alembic batch_operations takes care of this for us if we
use it so the alter and drops were converted to use batch operations.

Here's an example downgrade:

    with op.batch_alter_table('ps_endpoints') as batch_op:
        batch_op.drop_column('tos_audio')
        batch_op.drop_column('tos_video')
        batch_op.add_column(sa.Column('tos_audio', yesno_values))
        batch_op.add_column(sa.Column('tos_video', yesno_values))
        batch_op.drop_column('cos_audio')
        batch_op.drop_column('cos_video')
        batch_op.add_column(sa.Column('cos_audio', yesno_values))
        batch_op.add_column(sa.Column('cos_video', yesno_values))

    with op.batch_alter_table('ps_transports') as batch_op:
        batch_op.drop_column('tos')
        batch_op.add_column(sa.Column('tos', yesno_values))
    # Can't cast integers to YESNO_VALUES, so dropping and adding is required
        batch_op.drop_column('cos')
        batch_op.add_column(sa.Column('cos', yesno_values))

Upgrades from base to head and downgrades from head to base were tested
repeatedly for postgresql, mysql/mariadb, and sqlite3.

Change-Id: I862b0739eb3fd45ec3412dcc13c2340e1b7baef8

Kevin Harwell

691c0e0b31

res_pjsip_outbound_registration: registration stops due to fatal 4xx response

During outbound registration it is possible to receive a fatal (any permanent/
non-temporary 4xx, 5xx, 6xx) response from the registrar that is simply due
to a problem with the registrar itself. Upon receiving the failure response
Asterisk terminates outbound registration for the given endpoint.

This patch adds an option, 'fatal_retry_interval', that when set continues
outbound registration at the given interval up to 'max_retries' upon receiving
a fatal response.

ASTERISK-25485 #close

Change-Id: Ibc2c7b47164ac89cc803433c0bbe7063bfa143a2

3 Commits (69a2bc15b51d397055b0e685a857b2c5005c0e02)