Регулярные выражения в направлениях

dimas · Сообщение **dimas** » Вт дек 08, 2009 09:29

Приветствую всех.
Прошу помощи в понимании проблемы,
в опредении регулярных выражения

id prefix name create_date is_deleted
2954 ^81038044[0-9]{7}$ Ukraine (fix) - Kiev (area) 1260199967 0
5116 ^810380445[0-9]{5}$ Ukraine (fix) - Kiev 1260198455 0

если позвонить 810(380445)12345 нормально определяется
810(38044)5234567 - направление не определяется

что сделано не так ? Если удалить запись 5116, начинает нормально работать. и еще ^81038044 такой префикс вообще не работает

спасибо.

./utm5_core -v
?Debug : Dec 07 18:38:46 Rehash: Rehash manager started
Notice: Dec 07 18:38:46 ModMap: Sub-Module 'rehash' inserted...
NetUP UTM billing system core. Compile date: Oct 22 2009 12:21:18
Version:5.2.1-007-update4-centos5

JAO · Сообщение **JAO** » Вт дек 08, 2009 17:23

2954 ^81038044[012346789]{1}[0-9]{6}$ не оно? Как я понял, в первом определении нет пятерки после 38044, то есть все цифры, кроме пятерки, составляют направление Kiev (area).

dimas · Сообщение **dimas** » Ср дек 09, 2009 13:17

JAO писал(а):2954 ^81038044[012346789]{1}[0-9]{6}$ не оно? Как я понял, в первом определении нет пятерки после 38044, то есть все цифры, кроме пятерки, составляют направление Kiev (area).

Не, немного не так, на направление Киев, ^81038044[0-9]{7}$, как раз после 044 есть все цифры от 0 до 9, но их длинна 7 знаков.
Если удалить регулярку ^810380445[0-9]{5}$, то все начинает работать, как надо.

Вся идея заключена в следующем, что если если у меня не описан какой-либо код Киевской области, чтобы тупо подставлялся код Киева.
хотел сделать так ^81038044, но зараза, тоже не пашет

не понятно

gil · Сообщение **gil** » Ср дек 09, 2009 13:42

а местами поменять направления не пробовали?

dimas · Сообщение **dimas** » Ср дек 09, 2009 16:08

gil писал(а):а местами поменять направления не пробовали?

А какой смысл ?
У меня в БД много таких косяков, ведь логично обработать все выражения, и подставить то, которое подошло, у меня же прописано то выражения , что должно сработать

mikkey finn

пишите баг репорт. По докам - оно должно отсортировать все направления по длине, потом начинать просмотр с максимально точных к максимально общим.
Так что скорее бага в классификаторе.

gil · Сообщение **gil** » Чт дек 10, 2009 08:10

dimas писал(а):
gil писал(а):а местами поменять направления не пробовали?
А какой смысл ?
У меня в БД много таких косяков, ведь логично обработать все выражения, и подставить то, которое подошло, у меня же прописано то выражения , что должно сработать

да у них может и first match сработать, это же netup..
хотя, длина выражений-то разная..
в общем, это глюк..

dimas · Сообщение **dimas** » Чт дек 10, 2009 10:58

gil писал(а):
dimas писал(а):
gil писал(а):а местами поменять направления не пробовали?
А какой смысл ?
У меня в БД много таких косяков, ведь логично обработать все выражения, и подставить то, которое подошло, у меня же прописано то выражения , что должно сработать
да у них может и first match сработать, это же netup..
хотя, длина выражений-то разная..
в общем, это глюк..

В общем плотно работаем с саппортом нетапа, как что решиться или выясниться проблема я отпишу, вдруг кому-нибудь пригодиться.

dimas · Сообщение **dimas** » Ср дек 16, 2009 10:37

dimas писал(а):
gil писал(а):
dimas писал(а):
gil писал(а):а местами поменять направления не пробовали?
А какой смысл ?
У меня в БД много таких косяков, ведь логично обработать все выражения, и подставить то, которое подошло, у меня же прописано то выражения , что должно сработать
да у них может и first match сработать, это же netup..
хотя, длина выражений-то разная..
в общем, это глюк..
В общем плотно работаем с саппортом нетапа, как что решиться или выясниться проблема я отпишу, вдруг кому-нибудь пригодиться.

Проблема оказалась во включенном режиме enable_fast_telephony
выключил и все стало работать.