Sun-fire: Комментарии

Главные вкладки

4 июля 2012 в 0:37

Вариантов решения, как правило, большое множество Smile

Кстати, Ваш вариант решения позволяет все сделать наиболее быстро.

Такой уж внутренний формат хранения данных у коммерца. Не всегда удобно с нима работать. Например, некоторое время назад, было довольно трудно заставить работать Search API Ranges, пока не создали под него патч.

21 июня 2012 в 22:00

Feeds штука хорошая. Он не только RSS, но и XML нормально разбирает. Об CSV вообще молчу. Но как и все универсальные средства не лишен недостатков.

Самый основной его недостаток, с которым мне пришлось столкнуться - это его относительная медлительность. Если нужно выгрузить данные на сайт, и изредка их приводить в соответствие - Feeds именно то, что нужно. Если нужно поддерживать актуальность при большом объеме данных - то этот модуль уже мало чем поможет. А так - штука очень и очень полезная.

20 июня 2012 в 19:39

"Ch" wrote:
Каким образом? Ревизии у сущностей?

Да, если что-либо изменилось - создается новая ревизия. У нод это уже давно было, а в коммерце месяца два назад как появилось. Для избежания не контролированного роста базы - старые ревизии, у которых дата создания превышает некоторую величину чистятся. Это тоже организовано через очереди и node_revision_delete().

20 июня 2012 в 19:29

"Koreychenko" wrote:
Если речь про Drupal 6, то в нем Queue такая же "нештатная" вещь, как и Elysia Cron

Упс Smile Сорри, не заметил, что речь идет о Drupal 6, там и в правду Queue в ядре нет.

20 июня 2012 в 16:56

"Ch" wrote:
Обновлялись сущности целиком или только некоторые поля отдельно?

Первая версия модуля предусматривала изменения на уровне полей. Во второй (текущей) версии обновляются сущности целиком. Это позволяет отслеживать что, когда, и как изменялось (цены, наличие, и т. п.)

20 июня 2012 в 14:37

"Koreychenko" wrote:
Обновление цены можно делать непосредственно работая с базой, без Drupal API, это будет очень быстро.

В предыдущей версии модуля так и было организовано. Безусловно - выигрыш от такого подхода на лицо. Но в моем случае пришлось от него отказаться: меняется не только цена, но и наличие на складах, кроме того такой подход не самый лучший для организации версионирования цены.

20 июня 2012 в 12:38

Писал решение для импорта/обновления номенклатур в интернет-магазине. На данный момент в базе около 38К номенклатур, в ближайшее время количество должно вырасти до 70-80К. (Поскольку используется Drupal Commerce, то сущностей в два раза больше)

14 июня 2012 в 13:05

Вариант первый: разрешить на сайте формат полей РНР, и тогда в обычном поле с форматом РНР задать сниппет.
Вариант второй: установить модуль Views РНР и добавить поле РНР. плюс этого метода, что в поле становятся доступны переменные вьюхи (не всегда стабильно работает, но для большинства задач достаточно).

31 мая 2012 в 0:29

Для импорта можно использовать например эти модули:

А вообще для более точного ответа нужно знать детали задачи, поскольку сейчас в задаче это 10К "сферических страниц в вакууме". Большое значение играют факторы, как например: периодичность обновления, требования к скорости загрузки, технические параметры платформы, на которой все это будет работать и т.п.

16 мая 2012 в 17:24

Как вариант напрашивается выводить вьюхи программно через Display Suite в кодовом поле. Тогда все прекрасно контролируется.

В догонку: можно конечно и в темплейте это делать, но такой вариант не drupal way.