Отключение Ext.data.Model.identifier
 

Здравствуйте!

Можно ли выключить генератор ключей Ext.data.Model.identifier для модели?

Более подробно вопрос:

Если я правильно понимаю ваш вопрос, то генератор не нужно выключать. При создании записи (экземпляра модели) ей присваивается внутренний id и статус фантомной, т.е. не существующей на сервере.

Когда Store отправляет записи на сервер, они передаются с фантомным id. Нормальный протокол со стороны сервера, в цикле по каждой записи:

1. Сохраняем переданный фантомный id в переменную
2. Пишем запись в базу
3. Создаём объект для возврата
4. Реальный сгенерированный базой id возвращаем в поле idProperty
5. Старый фантомный id возвращаем в поле clientIdProperty
6. Сохраняем возвратный объект в массив для возврата и идём к следующей записи

Такой же механизм будет использоваться и для отдельных экземпляров моделей, без Store. Смотрите документацию: http://docs.sencha.com/extjs/5.1/5.1...ientIdProperty

Ещё могу предложить посмотреть пример (более/менее) правильной реализации CRUD: https://github.com/nohuhu/HTML5-Star...Direct/Base.pm. Я над этим проектом потихоньку работаю в свободное время. Это не PHP, но при желании разберётесь. ;)

спасибо за ответ - буду разбираться

а зачем вообще нужен этот фантомным id тогда?

Записи, хоть и фантомные, идентифицировать как-то надо. Например, для вывода в Grid. Кроме того, фантомные записи могут вообще никогда не получить реальный идентификатор, если их на сервер не сохранят или сервер отобьёт попытку сохранения. Все операции с записями отслеживаются по внутреннему id, который может не совпадать с "реальным".

nohuhu

Спасибо за подробные разъяснения! А дальше то как быть? Вот клиент получил свой старый фантомный id, нашел node с этим id и что? Сделал node.setId(newId)? Node станет dirty и будет отправлен серверу для апдейта в ближайший store.sync()... И по что оно нам такое? Апдейтить то в этом node попросту нечего! Как быть?

Буду благодарен за разъяснения.

@AirGraph,

Если сервер соблюдает конвенции и отвечает на запрос сохранения массивом с правильной привязкой clientId -> id, то Store отработает такой ответ самостоятельно и снимет фантомный флаг с сохранённых записей. В грязное состояние такие записи попадать не должны, как раз наоборот.

Можете воспроизвести проблему в Fiddle?

@nohuhu

Спасибо за пояснения.

У меня не сервер, а так, кое-какой модуль в Node JS, который мало-мало что-то читает/пишет в mongoDB. Я пытался по Вашей рекомендации возвращать запросу store.sync() JSON, содержащий id и clientId - treeStore никак на это не реагирует. Реально присвоенные в mongoDB id_ы не становятся таковыми в treeStore...

Начинать мне наверное надо не с публикации кода, а с прочтения доков на тему - как корректно организовать связь между treeStore и веб-сервером. Если оно где-то описано, поделитесь пожалуйста ссылкой. Возможно я чего-то базового не понимаю, от того у меня и вопросы такие странные... :-)

@nohuhu

С десятого раза вроде как заработало. С двумя оговорками:

1. В ответе сервера id должен быть указан именно так, как он определен в модели. Т.е. если в модели idProperty: '_id', то и в ответе сервера должно быть {_id: serverDefinedId, clientId: phantomExtId}. Ответ типа {idProperty: serverDefinedId, clientId: phantomExtId} не канает, что совсем не есть гуд... :-)

2. Порядок перечисления элементов в массиве ответа не обратный, как написано вот тут: http://docs.sencha.com/extjs/5.1/5.1...ientIdProperty, а прямой.

Доку на протокол обмена данными TreeStore с сервером хотелось бы увидеть в любом случае.

Спасибо.