Компания Google открыла (http://google-opensource.blogspot.ru/2014/11/lovefield-power...) под лицензией Apache код проекта Lovefield (https://github.com/google/lovefield), в рамках которого подготовлен движок для работы с традиционными реляционными базами данных в web-приложениях. Lovefield использует для постоянного хранения данных API IndexedDB (http://www.w3.org/TR/IndexedDB/) и позволяет манипулировать данными с использованием SQL-подобных запросов. Движок оформлен в виде JavaScript-библиотеки, которую можно использовать в различных браузерах, в том числе в Chrome 37+, Firefox 31+ и IE 10+.
Запросы оформляются в виде (https://github.com/google/lovefield/blob/master/docs/spec_in...) похожем на SQL, но имеют декларативный синтаксис, что позволяет обойтись без стадии парсинга и обеспечить защиту от атак по подстановке SQL-запросов. Разработчик вначале составялет (https://github.com/google/lovefield/blob/master/docs/quick_s...) схему, определяющую структуру БД. Затем данная схема компилируется в JavaScript-файл с обработчиком, который подключается к web-проекту и позволяет отправлять запросы только в рамках определённой схемы. Запросы отправляются в объектной форме, например, "var query = db.select().from(card).where(card.id.eq('12345'));".
Для достижения высокой производительности в Lovefield используется оптимизатор запросов, который рассматривает оптимальность различных планов выполнения запроса и выбирает наиболее эффективный. Lovefield обеспечивает приемлемую производительность для БД размером до 50 тысяч строк. В дальнейшем планируется внести оптимизации, которые позволят использовать Lovefield и для более крупных наборов данных.Основные особенности (https://github.com/google/lovefield/blob/master/docs/spec_in...) Lovefield:
- Поддержка запросов select, insert, update и delete;
- Простая семантика транзакций для обеспечения атомарности операций;
- Возможность задания ограничений для проверки сохранения целостности (primary key, unique, nullable/not-nullable).
- Поддержка агрегатных функций(count, min, max, sum, avg, stddev, distinct);
- Поддержка группировки в SELECT-запросах через выражение "group by";
- Возможность (https://github.com/google/lovefield/blob/master/docs/spec/04...) формирования запросов, охватывающих несколько таблиц (INNER JOIN, OUTER JOIN);
- Более простой, чем в IndexedDB, механизм изменения схемы данных.URL: http://google-opensource.blogspot.ru/2014/11/lovefield-power...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41078
Чем больше ресурсов, тем больше они распыляются :(p.s. Говорят что уровень парниковых газов в атмосфере продолжает активно расти, не смотря на все применяемые меры, думаю использование интерпретаторов интерпретаторов в программных контейнерах уже вносит значительную лепту в этот рост
Да, мощности компьютеров растут не для больших вычислений, а для абстракций абстракций. В конце концов, интерпретаторы интерпретаторов дорастут до одной команды - "Сделать звиздато" или "Принеси мне целое состояние"
У абстракций абстракций зато отличная стабильность стабильности и высокая переиспользуемость переиспользуемости.
Не, против абстракций, как таковых, я ничего не имею. В конце концов, даже писать на асме - это уже абстракция :) Но когда всё переносится в веб технологии, это уже перебор. Должна быть та грань, за которую нельзя переходить.
Это вам следовало сказать когда выпустили первую Джаву.
Для работы с сабжем требуется: Java, Python, node.js, closure !
>Запросы оформляются в виде похожем на SQL, но имеют декларативный синтаксисА у SQL синтаксис недекларативный, да?
>>Запросы оформляются в виде похожем на SQL, но имеют декларативный синтаксис
> А у SQL синтаксис недекларативный, да?они решили решить неразрешимую для многих решателей пишущих решения на js|php и т.п. проблему query("select name from "+valTable+" where "+valField+"=" + valID ";") нетрадиционным способом, но забыли о том что теперь можно написать:
eval("db.select.from("+valTable+").where("+valField+".eq("+valID+"))")...в принципе похвально конечно, теперь можно будет знатокам js и sql писать код а потом компилировать его в c++ :)
> забыли о том что теперь можно написать:
> eval("db.select.from("+valTable+").where("+valField+".eq("+valID+"))")...Это вы к:
>обойтись без стадии парсинга и обеспечить защиту от атак по подстановке SQL-запросов.
?
Ну дык чтобы eval сработал надо внедрить код, а там уже всё бесполезно. Речь идёт про другие атаки, про т.н. SQL-inj, когда в valTable оказывается совершенно иной sql запрос. Когда составление sql-запроса -- это не тупо конкатенация строк, а так как в этом фреймворке сделано, фреймворк может экранировать всё, причём прозрачно. Правда тут есть другой косяк: он экранировать будет всё, даже то что передано в виде literal'ов, потому что в рантайме не сможет отследить, что литерально, а что из переменной берётся. Но жабаскрипту на это пенальти к производительности я полагаю насрать: одним пенальти больше, одним меньше -- всё равно тормоз.
Никто не мешает составлять запросы через параметры, как это делается в нормальных системах, но увы и в нормальных системах у многих выходит через контактацию строк :)
Поясните для тупых: БД прямо в браузер передаётся?
> Поясните для тупых: БД прямо в браузер передаётся?БД прямо в нём живёт на 10-м уровне изоляции в виде куков ;)
Не только куков. История, закладки, пароли, - всё лежит в БД. Даже копирасты вроде Apple используют SQLite для своих браузеров.
> Не только куков. История, закладки, пароли, - всё лежит в БД. Даже
> копирасты вроде Apple используют SQLite для своих браузеров.и у вас есть доступ со старницы в SQLit-овскую БД?
Нет, этого я не говорил. Было бы глупо давать доступ сайтам к этой информации. Бездонное поле для уязвимостей.
Кстати вот очень жаль, что нет. При том, что она присутствует и в Firefox и в Chrome и в других браузерах на их основе (т.е. совокупно - на большинстве клиентов) давно пора дать к web-приложениям к ней доступ через нормальный SQL и перестать морочить людям голову. Хотя нет, они сами себе её заморочат - тут же нагородят кучу всяких ORM...
Это хорошая и давно ожидаемая новость.В конечном итоге можно будет писать single-page application с нормальной MVC и постоянным хранением данных на стороне клиента.
Представьте RoR-подобный framework на стороне пользователя.
С нормальной - очень вряд ли. Я пока в веб-приложениях ничего нормального не видел. Ни модульности, ни описания GUI, ни работы с данными. Вот костылей - да, много.
А их и не будет. До тех пор, пока из сверхпримитивных элементов будем пытаться построить GUI. Пора бы нам признать, что из "языка разметки гипертекста" не выйдет нормального фреймворка для гуевых сетевых приложений.
>В конечном итоге можно будет писать single-page applicationНинада! Вот только что: http://mobile.dzone.com/articles/single-page-web-apps-worst .
> в Chrome 37+, Firefox 31+ и IE 10+Opera 12 нет, значит не нужно.
Толсто или тонко? А браузер (O12) до сих пор рабочий.
Так есть уже куки, Local Storage, IndexedDb и Web SQL Database. Но нужно больше хранилищ!Кстати, "db.select().from(card).where(card.id.eq('12345'));" - не SQL ни разу, это как раз пародия на без того убогий API MongoDB. Зачем он на клиенте - я правда не знаю.
Вот как раз на замену Web SQL Database, его же выпилить собираются, а первые два ключ-значение.