1. Какую ошибку вернуть — это целиком и полностью на вашей совести. Можно и что нибудь из 4хх кодов подобрать ( en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error ), и в теле присовокуплять, почему именно ошибка. Отправлять наружу тексты SQL ошибок, конечно же, не стоит.
2. Да. Клиент всегда может прислать любую ересь. Более того, клиент может прислать правильный запрос, который стал не валиден из-за действий других клиентов или программ. Например, пытается забронировать билет, а они все только что кончились. С точки зрения клиента и фронта — полностью валидная операция, с точки зрения БД и бэкэнда — уже не валидная.
Вообще говоря, в доке написано про one-to-one relationship between the rows in the view and the rows in the underlying table. В комментариях есть фраза «For a multiple-table updatable view, INSERT can work if it inserts into a single table.», но это тоже не запрет, а описание поведения.
Про пункты 1-2, я это понимаю. Но вы в начале статьи подобные требования не упоминали, так что я их не рассматривал.
Про ваш пункт 0 — так ваш ORM позволяет делать селекты из view, а инсертить при этом непосредственно в таблицу? Вы в этом случае не будете таскать с собой джоины, и при этом правильно инсертить будете.
В нормальном продукте логика верификации должна быть как в приложении (в рамках фильтрации поступивших от пользователя данных), так и в БД, если она в принципе это позволяет, и если производительность БД позволяет это делать. Фича практически любой взрослой SQL базы данных заключается в том, что она может поддерживать целостность данных в связанных таблицах, другое дело, что многие про это не хотят думать.
Увидел большую С в середине запроса, действительно. Рекомендую делать иллюстрации более иллюстративными :) а именно — называть похожие сущности более разными именами, чтобы не вводить читателей в заблуждение.
Про инсерты в view: вы с какой именно целью во view делаете инсерты? Из вашего примера не видно ни одного плюса. Вы хотите заполнять сразу 3 таблицы за 1 запрос? Но зачем, если там 3 разные сущности?
The WITH CHECK OPTION clause can be given for an updatable view to prevent inserts or updates to rows except those for which the WHERE clause in the select_statement is true.
И тут, похоже, проблема заключается в том, что в момент проверки значение b_id пустое.
Кстати, не боитесь наинсертить в таблицы A и B записей с пустыми полями name? В вашем примере смысла вставлять именно во view ну совсем никакого. Или у вас глупый ORM и он по-другому не умеет?
Как-то неэффективно используются адреса, даже на вашей картинке это видно. Если вместо 127.0.0.80/29 и 127.0.0.104/29 использовать 127.0.0.8/29 и 127.0.0.16/29, а вместо 127.0.0.160/27 — 127.0.0.32/27, то у вас освободится 127.0.0.128/25 и 127.0.0.64/26.
На первый взгляд, для подобных задач должно хорошо подойди нечто типа SLAB аллокатора, на 5 арен для этой картинки (/28, /27, /26, /25, /24). Допустим, надо выделить блок /28, тогда алгоритм примерно такой:
1. Смотрим, есть ли в арене /28 свободные блоки. Если есть — берём один блок и помечаем его как занятый.
2. Если нету — то идём в арену /27 и берём оттуда свободный блок. Если есть — то изымаем его из этой арены, а в арену /28 помещаем две его половинки. Если нету — то рекурсивно идём наверх. Если в самой крупной арене (/24, в данном случае) ничего нету, то извиняемся перед клиентом.
При освобождении блока возвращаем его в арену соответствующего размера. Если есть 2 блока, которые можно склеить и вернуть в вышестоящую арену — делаем это рекурсивно.
Иногда можно делать дефрагментацию, если договоры с клиентами позволяют менять адреса по запросу хостера.
Плюс данной схемы с в том, что она старается размещать блоки как можно компактнее. Минус в том, что фрагментация всё равно будет. С учётом того, что вам надо /32 адреса клиентам выдавать, придётся делать арены вплоть до /31.
Если хочется просто воткнуть железку от мелланокса и сразу получить буст в скорости/задержке, ничего не меняя в коде — то это у них называется VMA ( ru.mellanox.com/page/software_vma?mtag=vma). Аппаратный оффлоад TCP/IP стека, уменьшает latency.
RDMA over Ethernet работает только если обе карты эзернетовские, да ещё и специальный свитч (эзернет, но от мелланокс) стоит. И код естественно переписать придётся под RDMA, а там всё по-другому (в конце презентации есть про это www.docstoc.com/docs/2705254/Introduction-to-RDMA-Programming).
Могу дать контакты их московского продажника (именно мелланоксовского, не посредника).
Кстати да, про руководство. VMA пробовали включать? Мне показывали лабу, latency в одну сторону между двумя машинками падала с 9.5мкс до 1.5мкс для мелких пакетов.
USART позволяет записать в буфер 1 байт данных, которые на выходе выплюнутся в ножку микросхемы. www.atmega8.ru/wiki/view/doc.17.html. Скорость, в которой биты выплёнываются в провод настраивается.
Кодирование, которое вы описали, увеличивает в 2 раза количество данных, то есть 1 бит информации (допустим, 0) превращается в 2 бита в проводе (01 или 10). То есть 1 байт данных после кодирования превратится в 2 байта. Никакой магии, алгоритм просто и понятен, примерно это у вас изображено в функции selectPulse().
Если совместить эти 2 факта — то можно максимально разгрузить вычислительное ядро атмеги и заставить работать блок USART. Тут подставу могут организовать старт-стоп биты и контроль чётности, придётся поэкспериментировать в эмуляторе или с осциллографом, ну или с той же audacity. Возможно, придётся использовать USART в режиме SPI-мастера и использовать ножку передачи данных.
Я такое на практике не делал, но поэкспериментировать в этом направлении определённо имеет смысл.
Кстати, вы не пробовали отправлять такую последовательность используя UART, и скармливать ему сразу байты (скорость в 2 раза увеличить, байты предварительно закодировать)?
Я себе в декабре купил телевизор, который поддерживает 3D, понятное дело, сразу полез пробовать в деле, накопал такие знания:
— видео чаще всего — горизонтальная или вертикальная пара, при этом бывают сжатые вдвое (2 кадра впихнули в 1920х1080), бывают 2 кадра рядом, при этом размер видеополя в 2 раза увеличивается. Телевизор хочет сжатые кадры, качество оптимальное при вертикальной паре (один кадр над другим).
— телевизор понимает черезстрочную пару (то, что вы сделали), видео в таком формате сходу не нашлось. Теоретически бывают пары с порядком пикселей как у шахматной доски. На сколько я понимаю, современные видеокодеки такое не любят.
— теоретически mpeg4 поддерживает возможность хранить знания о типе пары, но мне такие ролики не попадались.
— теоретически есть mpeg4 стерео режим. Кодеков сходу не нашёл. Роликов тоже не нашёл.
— видеокарточки от NVidia, AMD и Intel умеют выводить 3D видео в HDMI со специальными метками кадров, телевизор сразу подхватывает и переключается в 3D режим, работает в полноэкранном режиме. У всех трёх производителей API, конечно же, совершенно разное. У AMD надо переключать кадры спец. функцией, у NVidia делать хитрую текстуру, у Intel вообще инициализировать перед созданием поверхности, на которую будет отрисовка.
Когда растамаживал крепления для сноуборда (DHL, 6000р, лимит тогда был 5000р) — печатал инвойс, брал выписку из банка, это и было доказательством реальной стоимости.
Похоже, вы как-то связаны с Рамблером, возможно, даже работали там. Расскажете про проблемы с эллиптиксом в почте и аватарнице? Мы тут с коллегами у рамблеровцев спросили, они говорят, что и в почте, и в аватарнице эллиптикс всех устроил, а проекты заморозили совсем по другим причинам.
На сколько я знаю про Рамблер — там забили на почту, а не на эллиптикс. В начале этой осени они ещё пилили почтовик и всё вокруг, чтобы туда данные сложить. Говорят, ещё аватарницу там на эллиптиксе подняли, но есть некоторые сомнения, не зарубили ли проект на стадии выкладки в продакшен.
В Яндексе, на сколько я в курсе, именно с эллиптикса никуда не уходили. Было такое, что долго выбирали и в итоге выбрали HBase по совокупности характеристик, но это же совсем другая история. Про KIWI ничего говорить не буду, уйти туда с эллиптикса в общем случае нельзя.
Много неочевидных нюансов есть у любой более-менее сложной системы. Есть они и у Riak, есть и у CEPH, и у HDFS. В итоге выбирается наименее плохая система из подходящих.
2. Да. Клиент всегда может прислать любую ересь. Более того, клиент может прислать правильный запрос, который стал не валиден из-за действий других клиентов или программ. Например, пытается забронировать билет, а они все только что кончились. С точки зрения клиента и фронта — полностью валидная операция, с точки зрения БД и бэкэнда — уже не валидная.
Про пункты 1-2, я это понимаю. Но вы в начале статьи подобные требования не упоминали, так что я их не рассматривал.
Про ваш пункт 0 — так ваш ORM позволяет делать селекты из view, а инсертить при этом непосредственно в таблицу? Вы в этом случае не будете таскать с собой джоины, и при этом правильно инсертить будете.
В нормальном продукте логика верификации должна быть как в приложении (в рамках фильтрации поступивших от пользователя данных), так и в БД, если она в принципе это позволяет, и если производительность БД позволяет это делать. Фича практически любой взрослой SQL базы данных заключается в том, что она может поддерживать целостность данных в связанных таблицах, другое дело, что многие про это не хотят думать.
Про инсерты в view: вы с какой именно целью во view делаете инсерты? Из вашего примера не видно ни одного плюса. Вы хотите заполнять сразу 3 таблицы за 1 запрос? Но зачем, если там 3 разные сущности?
dev.mysql.com/doc/refman/5.5/en/view-updatability.html:
И тут, похоже, проблема заключается в том, что в момент проверки значение b_id пустое.
Кстати, не боитесь наинсертить в таблицы A и B записей с пустыми полями name? В вашем примере смысла вставлять именно во view ну совсем никакого. Или у вас глупый ORM и он по-другому не умеет?
На первый взгляд, для подобных задач должно хорошо подойди нечто типа SLAB аллокатора, на 5 арен для этой картинки (/28, /27, /26, /25, /24). Допустим, надо выделить блок /28, тогда алгоритм примерно такой:
1. Смотрим, есть ли в арене /28 свободные блоки. Если есть — берём один блок и помечаем его как занятый.
2. Если нету — то идём в арену /27 и берём оттуда свободный блок. Если есть — то изымаем его из этой арены, а в арену /28 помещаем две его половинки. Если нету — то рекурсивно идём наверх. Если в самой крупной арене (/24, в данном случае) ничего нету, то извиняемся перед клиентом.
При освобождении блока возвращаем его в арену соответствующего размера. Если есть 2 блока, которые можно склеить и вернуть в вышестоящую арену — делаем это рекурсивно.
Иногда можно делать дефрагментацию, если договоры с клиентами позволяют менять адреса по запросу хостера.
Плюс данной схемы с в том, что она старается размещать блоки как можно компактнее. Минус в том, что фрагментация всё равно будет. С учётом того, что вам надо /32 адреса клиентам выдавать, придётся делать арены вплоть до /31.
RDMA over Ethernet работает только если обе карты эзернетовские, да ещё и специальный свитч (эзернет, но от мелланокс) стоит. И код естественно переписать придётся под RDMA, а там всё по-другому (в конце презентации есть про это www.docstoc.com/docs/2705254/Introduction-to-RDMA-Programming).
Могу дать контакты их московского продажника (именно мелланоксовского, не посредника).
Исходная последовательность бит 00011001000000001111000
после кодирования 10 10 10 11 00 10 10 11 01 01 01 01 01 01 01 01 00 11 00 11 01 01 01
USART позволяет записать в буфер 1 байт данных, которые на выходе выплюнутся в ножку микросхемы. www.atmega8.ru/wiki/view/doc.17.html. Скорость, в которой биты выплёнываются в провод настраивается.
Кодирование, которое вы описали, увеличивает в 2 раза количество данных, то есть 1 бит информации (допустим, 0) превращается в 2 бита в проводе (01 или 10). То есть 1 байт данных после кодирования превратится в 2 байта. Никакой магии, алгоритм просто и понятен, примерно это у вас изображено в функции selectPulse().
Если совместить эти 2 факта — то можно максимально разгрузить вычислительное ядро атмеги и заставить работать блок USART. Тут подставу могут организовать старт-стоп биты и контроль чётности, придётся поэкспериментировать в эмуляторе или с осциллографом, ну или с той же audacity. Возможно, придётся использовать USART в режиме SPI-мастера и использовать ножку передачи данных.
Я такое на практике не делал, но поэкспериментировать в этом направлении определённо имеет смысл.
Кстати, вы не пробовали отправлять такую последовательность используя UART, и скармливать ему сразу байты (скорость в 2 раза увеличить, байты предварительно закодировать)?
— видео чаще всего — горизонтальная или вертикальная пара, при этом бывают сжатые вдвое (2 кадра впихнули в 1920х1080), бывают 2 кадра рядом, при этом размер видеополя в 2 раза увеличивается. Телевизор хочет сжатые кадры, качество оптимальное при вертикальной паре (один кадр над другим).
— телевизор понимает черезстрочную пару (то, что вы сделали), видео в таком формате сходу не нашлось. Теоретически бывают пары с порядком пикселей как у шахматной доски. На сколько я понимаю, современные видеокодеки такое не любят.
— теоретически mpeg4 поддерживает возможность хранить знания о типе пары, но мне такие ролики не попадались.
— теоретически есть mpeg4 стерео режим. Кодеков сходу не нашёл. Роликов тоже не нашёл.
— видеокарточки от NVidia, AMD и Intel умеют выводить 3D видео в HDMI со специальными метками кадров, телевизор сразу подхватывает и переключается в 3D режим, работает в полноэкранном режиме. У всех трёх производителей API, конечно же, совершенно разное. У AMD надо переключать кадры спец. функцией, у NVidia делать хитрую текстуру, у Intel вообще инициализировать перед созданием поверхности, на которую будет отрисовка.
Форкаете, патчите код (обязательно закрыв изменения ифдефами), коммитите, делаете пулл реквест. Всё!
В Яндексе, на сколько я в курсе, именно с эллиптикса никуда не уходили. Было такое, что долго выбирали и в итоге выбрали HBase по совокупности характеристик, но это же совсем другая история. Про KIWI ничего говорить не буду, уйти туда с эллиптикса в общем случае нельзя.
Много неочевидных нюансов есть у любой более-менее сложной системы. Есть они и у Riak, есть и у CEPH, и у HDFS. В итоге выбирается наименее плохая система из подходящих.