Т.е. если разработчику понадобится еще одна база нужно будет править конфиг SQLFuse?
Если в patch'е было переименование директории, git при апдейте с точки зрения ФС это делает именно переименованием?
Вы писали, что «ограничения создаются в последнюю очередь», а как определяется в каких файлах содержатся ограничения? По префиксам файлов типа FK_* DF_*? И все равно не понятно как решается проблема очередности создания для остальных случаев, типа зависимости одной функции от другой.
Т.е. вы предлагаете следущую схему разработки: правка кода -> коммит -> деплой на тест -> синтаксическая ошибка -> снова правка кода -> коммит и т.д. пока наши правки не заработают?
А на сервере для каждого разработчика заводить отдельные директории и базы с которыми они будут синхронизироваться? Это можно сделать только правкой конфига? Или с помощью SQLFuse можно и базы создавать?
А как SQLFuse отслеживает сам факт переименования таблицы?
Не могли вы тогда привести пример как с помощью SQLFuse добавляются и удаляются поля с констрейнтами?
Т.е. я в момент разработки вношу изменения в файлы, их код выполняется с ошибкой и они бесследно исчезают?
Не могли бы вы подробнее рассказать непосредственно о SQLFuse? У меня сразу возникло несколько вопросов:
Каждому разработчику придется у себя локально разворачивать SQLFuse?
Пока из описания я не понял как отслеживается переименование сущностей, например, таблиц. Вот я переименовал в файловой системе директорию, которая соответствует таблице. SQLFuse это как-то определит и сделает ALTER TABLE, попутно изменив все foreign key, которые ссылаются на эту таблицу?
Как регулируются зависимости одних изменений от других? Вот допустим в одну таблице я добавил поле, а в другой сделай foreign key на это поле. Очевидно, что в неверной последовательности, изменения не накатятся
Вы упомянули, что в случае неудачной попытки изменений «приводится в соответствие иерархия файлов и директорий с их фактическим состоянием относительно БД». Т.е. в так случае у нас получается «грязная» рабочая копия, в которой файлы не соответствуют текущей ревизии?
у Samsung великолепно налажены каналы сбыта, как в своё время у Nokia. Надо будет — продадут что угодно.
Не продадут. Нокия не смогла продать WP. Самсунг въехал на рынок смартфонов только благодаря android'у, который мощно продвигал google. Android (как и iOS) это не только mobile OS, но и инфраструктура, которой у самсунга нет и создать ее они вряд ли смогут. Вы можете представить себе классные облачные сервисы от самсунга (почта, карты, поисковик)? думаю, вряд ли. Без этого современная мобильная ОС неконкуретноспособна.
Что вы думаете по поводу Host-based Card Emulation, который появился в Android 4.4? Похоже гугл идет в сторону отказа от secure element'а. Возможна ли в будущем работа вашего Кошелька в аппаратах без secure element'а, но с поддержкой HCE?
А вы думаете, что сможете прийти в российский магазин и купить планшет nvidia за $200? Во-первых, добавьте к этой стоимости НДС ($36), во-вторых, жадность наших ритейлеров. Думаю у нас он если и будет продаваться, то никак не меньше чем за $300. Посмотрите, например, на цену nexus 7 (прошлого покления) в российской рознице.
Раньше на 14 дюймах и на 800x600 жили. И что теперь отказаться от технического прогресса что ли? Те кто видел как выглядит картинка с высоким ppi вряд ли захотят покупать планшет за $200 с низким разрешением, особенно учитывая то, что за $229 можно купить Nexus 7 FHD или Kindle Fire HDX, у которых разрешение 1920x1080.
Не продадут. Нокия не смогла продать WP. Самсунг въехал на рынок смартфонов только благодаря android'у, который мощно продвигал google. Android (как и iOS) это не только mobile OS, но и инфраструктура, которой у самсунга нет и создать ее они вряд ли смогут. Вы можете представить себе классные облачные сервисы от самсунга (почта, карты, поисковик)? думаю, вряд ли. Без этого современная мобильная ОС неконкуретноспособна.
Что-то с трудом верится