LINUX.ORG.RU

ScalaQL, ассиметричный ответ на LINQ

 , , ,


1

0

Даниэл Спевак и Тьян Жао представили библиотеку ScalaQL для языка Scala, предоставляющую возможность заменять ORM на SQL-подобные конструкции языка запросов, подобного LINQ.

>>> Подробности

Ответ на: комментарий от VoDA

LINQ - это шаг вперёд, конечно. Только это уже отход от ООП в сторону декларативного программирования. Разработчики С# вот поняли, что ООП - не панацея, и надо исследовать иные концепции. А джависты тем временем продолжают жевать кактус pure OOP, ещё и нахваливают.

Hjorn
()
Ответ на: комментарий от aist1

>нужно будет оббегать десяток разработчиков и спрашивать "я вот хочу эту сущность двинуть туда-то, это у тебя ничего не поломает?"

Это решается паттерном DataMapper

>семи этими делами года 4 назад перестал интересоваться ибо нефик голову захламлять.

Я тоже так решил. Потому пишу простой JDBC код с SQL запросами ручками.

dizza ★★★★★
()

SQL прекратите насиловат е

То я давно сразу говорил что хватит насиловать не надо сиквель и реляционние бази то они не для е того придуманы. Е то хорошо е когда надо много сложных данных в базу сложить а потом по им ИЗРЕДКА делать РАЗНЫЕ запросы ото для то-во они й придуманы. ТА ХВАТИТ В СВОЙ ВЕБ СУВАТЬ СИКУЭЛЬ полный тред дурнив че-то спорит в каких сапогах лучше стоя в гомаке в резинових то йли в кирзових то йле ваще в химзащити та ответ НЕ НАДО СИКУЭЛЬ. Есть другии хранилище данних учитеся уже думать головой а не тащитьвезде стандратние решения как медведики.

ce_tamotko_za_uzori
()
Ответ на: комментарий от Bioreactor

>Пожалуйста, пример в студию.

Пример чего? Кэш второго уровня не нужно кластеризовать в отсутсвии кэша второго уровня. Ты решаешь архитектурно-порожденную задачу. Вроде кластера для EJB который нужен только потому, что там есть EJB.

r ★★★★★
()

It's easy. It's fast. Delphi 2010 is addictive to use...It's pure joy

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Absurd

> Проблема тут может быть как раз со всякими ненужными слоями абстракции типа гибернейта которые сводят SQL к куцему общему знаметателю, оставляя за бортом разные аналитические расширения Оракла например.

У меня сложилось впечатление, что гибернейт не заслуживает громкого названия "слои абстракции", а скорее, что это перефасовщик из одного тупого языка в другой тупой язык. Естественно, этот перефасовщик получается сложным, ибо взаимодействие двух тупых языков сопровождается impedance mismatch.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от r

К сожалению, я так и не получил конкретные ответы на мои вопросы.

----------------------------

> Кэш второго уровня не нужно кластеризовать в отсутсвии кэша второго уровня.

> Вроде кластера для EJB который нужен только потому, что там есть EJB.

Про распределение нагрузки в корпоративных приложениях ничего не слышали?

Bioreactor ★★★★★
()
Ответ на: комментарий от sv75

> Допустим, я решил сменить SQL-сервер.

И часто у вас такое?
В любом случае мне кажется лучше пересмотреть/переписать все запросы с учётом особенностей новой бд. Элементарный пример: вы работали с mssql и решили переехать на mysql. В mssql вложенные запросы чудесно работают и вы их активно используете. На mysql они какбы работают, но на больших объёмах данных видно, что это всеголишь какбы и все запросы придется всеравно переписывать на джоины, т.к. производительность неприемлимая. Так что sql sql-у рознь.
Зато интерфейс к данным внутри приложения останется прежним.


> Как их лучше всего класть в VCS?


Например, перед коммитом вызывать скрипт дампа процедур в файл(ы).


> У меня inner join с сотней полей, по каждому из которых может быть group by, where сложным образом и т.д. в зависимости от желания пользователя-аналитика


Внутри stp полноценный язык программирования. Раз уж нельзя избежать сложного динамического запроса, то его можно сгенерировать внутри, передав минимально необходимые параметры. Если параметров много, можно сериализировать их чем-то типа xml... не думаю что разбор того же xml будет медленнее шевеления уровня абстракции LINQ или ScalaQL.

d9d9 ★★★★
()
Ответ на: комментарий от Bioreactor

>Про распределение нагрузки в корпоративных приложениях ничего не слышали?

Для этого обязательно нужен EJB и кэш второго уровня?

Есть уйма других способов для распределения нагрузки. Банальная балансировка HTTP запросов, GridGain-ы всякие, Hadoop, Terracotta, MQ, JavaSpaces, и.т.д.

WFrag ★★★★
()
Ответ на: комментарий от Bioreactor

>Пруфлинк в студию.

Про сони проскакивало тут на лоре.

Про ксерокс вот: http://www.scala-lang.org/node/2766

>Да ну!

Ну да.

>А обосновать?

Да легко.

Начнем с того, что он часто используется там, где не нужен объектный маппинг в целевой язык вообще - вся задача сводится к засовыванию данных из базы в веб.

Продолжим тем, что под него необходимо создавать структуру базы данных, мапиться на существующую непредназначенную для него структуру он хреново, в связи с чем связка RDBMS/Hibernate - вообще бред, если работа происходит толко с объектами - нахрена там внизу RDBMS? В качестве неудобного транзакционного хранилища, в которое еще тот геморой запихивания данных, с которыми в реляционном виде работать неудобно и именно потому сверху строиться гибернейт? А потом надо делать кластера кэшей второго уровня. У тебя не создается ощущения маразма происходящего? У меня вот сильное.

Закончим тем что я работал с гибернейтом еще когда деревья были большими. Его сессионное апи тогда выглядело маразматично. Нам нужна была связь с недоскуэль платформой filemaker. Ну думали абстракция вся фигня сча наваяем быстренько платформу... Ага мечтай. Классы по 8000 строк кода в которых черт ногу сломит, куча циклических ссылок из якобы абстрактного кода на конкретный, никакой нормально абстракции платформы - такой ужас вообще редко увидишь - подходит студентам показывать спагетти код и как писать нельзя, провозились неделю, плюнули, а потом за 1 день написали новую платформу под Apache ObjectBridge, который спроектирован гораздо грамотнее.

И в качестве поскриптума - невменяемость Гэвина. Что можно сказать о человеке, который открывает транзакцию на read запрос сам, если она уже не открыта, при этом _не_ закрывает ее сам, а заставляет закрывать внешним кодом, а когда ему говорят, что он дважды неправ (и по поводу открытия вообще и по поводу автоматического незакрытия) и с пеной у рта доказывает по форумам, что "чтения без транзации не бывает". BEGIN SELECT COMMIT. Ага да - скажите, что он не болен.

Сильно надеюсь что его в жбоссе немножко уму-разуму научили. Иначе мне ужасно представить что кто-то еще мучается с этим.

r ★★★★★
()
Ответ на: комментарий от d9d9

>Внутри stp полноценный язык программирования. Раз уж нельзя избежать сложного динамического запроса, то его можно сгенерировать внутри, передав минимально необходимые параметры. Если параметров много, можно сериализировать их чем-то типа xml... не думаю что разбор того же xml будет медленнее шевеления уровня абстракции LINQ или ScalaQL.

Ага. Заодно решая тупые проблемы типа лишней или недостающий запятой, "AND/OR" и прочие прелести текстовой генерации SQL.

Уж лучше:

var q = from p in db.Person select new {p.FirstName, p.LastName };
if(lastName != null) {
q = from p in q where p.LastName == lastName;
}
var list = q.ToList();

WFrag ★★★★
()
Ответ на: комментарий от www_linux_org_ru

>это перефасовщик из одного тупого языка в другой тупой язык.

К сожалению, SQL это самый выразительный язык из того что есть в ынтерпрайзе.

Absurd ★★★
()
Ответ на: комментарий от Bioreactor

>Про распределение нагрузки в корпоративных приложениях ничего не слышали?

Слышали. А еще слышали, что кластеризовать нужно узкое место, а не кэш второго уровня. С покон веку типичных узких местов было 3: 1.база данных, 2.количество коннекшенов и 4. вычислительная нагрузка на сервер.

Кластеризуется: 1. кластер стредствами RDMBS. 2. DNSRR + наращивание количества серверов. 3. DNSRR + наращивание количества серверов / разнесение фронтэда и кластера процессоров (если процент тяжелых запросов мал).

Все прочие варианты кластеров - задачеспецифичны, и никакой гибернейт тут уже рядом не стоит.

Ты хоть знаешь почему этот геморой с кластером кэша нужен? Да потому что нужен кэш второго уровня. А зачем? А затем что гибернейт без него тормозит.

Если тебе надо кластеризовать гибернейт без планки на порцессоре сервера с RDBMS и в отсутствии тяжелой вычислительной логики, значит узким местом стал гибернейт. О чем я и говорю - архитектурно-порожденная задача. Ты не можешь проехать по мосту не потому что по мосту проехать нельзя - а потому что ты сильно здоровый гусеничный грузовик выбрал для этого.

r ★★★★★
()
Ответ на: комментарий от r

>>Пруфлинк в студию.

> Про сони проскакивало тут на лоре.

Понятно. Агенство "О.Б.С."

> Про ксерокс вот: http://www.scala-lang.org/node/2766

И что? Это "история успеха" ?

>>Да ну!

> Ну да.

Остроумнее Вас - только В.Шендерович.

>>А обосновать?

>Да легко.

Это не обоснование, а поток сознания. Аргументация проводится на конкретных примерах.

> невменяемость Гэвина

Ой-вей, Б-же мой, а Вы-таки уже врач с дипломом психиатора, раз диагноз устанавливаете?

> нахрена там внизу RDBMS

Да, pure-OODBMS Cache эффективней, однако, имеет свой собственный формат и имеет ограниченное число заказчиков. У меня был только один проект с Cache. Hibernate более востребован.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

О еще один жабщичек че

я когда пять лет назат тут писал че питон е то будущее тоже громче всех жабщики орали че недоезычок и без фигурных скобачек не нужин. и че? време идет мир меняется вот уже гуголь за петон взялсе а жабщики все те же

та дурни своево ума нету хоть на тот же гуголь смотрите где тамо sql где тамо ваши рдбмс? на амазон посмотри где тамо sql? вы головой хоть из окопа вертите иногда

ce_tamotko_za_uzori
()
Ответ на: комментарий от r

> У тебя не создается ощущения маразма происходящего? У меня вот сильное.

У меня тоже.

Но чтобы окончательно прояснить вопрос, надо выяснить, как писать свои оптимизаторы запросов к своему аналогу БД. ИМХО, тут надо что-то типа продвинутого ScalaQL.

> а потом за 1 день написали новую платформу под Apache ObjectBridge, который спроектирован гораздо грамотнее.

Интересно, взгляну. Они там сделали что-то для писания своих оптимизаторов запросов?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от r

> Да потому что нужен кэш второго уровня. А зачем? А затем что гибернейт без него тормозит.

Завязывайте с веществами.

"SessionFactory может поддерживать опциональный кэш для данных, которые используются несколькими транзакциями, этот кэш называют кэш второго уровня (second-level cache) или кэш уровня JVM (JVM-level cache). Данный кэш можно настроить таким образом чтобы он работал как для одного процесса (process-level) так и для нескольких процессов в кластере (cluster-level). " (с)

Bioreactor ★★★★★
()
Ответ на: комментарий от r

>и с пеной у рта доказывает по форумам, что "чтения без транзации не бывает"

Ну я для селектов тоже делаю транзакции. Боюсь чтение не закомиченных данных. А для подверждения что он read-only еще насильно делаю roll-back. Или это мой параноидальный бред?=)

dizza ★★★★★
()
Ответ на: комментарий от dizza

> А для подверждения что он read-only еще насильно делаю roll-back. Или это мой параноидальный бред?

сурово. а какова стоимость операции и потери?

Deady
()
Ответ на: комментарий от Deady

>сурово. а какова стоимость операции и потери?

Хз. Дядьки сказали, что roll-back "легче" commit. Хотя хз правда это или нет.

dizza ★★★★★
()
Ответ на: комментарий от dizza

>>сурово. а какова стоимость операции и потери?

>Хз. Дядьки сказали, что roll-back "легче" commit. Хотя хз правда это или нет.

Ну вообще когда проектируют БД то делают предполощение что Commit будет выполняться как минимум на один порядок чаще чем Rollback, т.к Rollback - это откат ошибки, а ошибки в нормальной системе бывают намного реже штатного поведения. Поэтому перформанс Rollback-а обычно разработчиков СУБД волнует в последнюю очередь. В Оракле Commit - O(1), а Rollback - O(N) от затронутых данных.

Absurd ★★★
()
Ответ на: комментарий от dizza

DataMapper позволяет только минимизировать объем вносимых изменений. А отслеживать consistency запросов всё равно должен какой-то выделенный инструмент.

Но это не самая большая беда. Хуже другое. Сущности прикладной модели данных - они, как правило, композитные. А RDBMS, имеющиеся в наличии, не умеют выполнять размещение данных с учетом логики обработки этих сущностей. Т.е. композитная сущность хранится нелокально и может быть размазана по всему хранилищу. С потерей производительности ессно. Поэтому, как не извращайся, rdbms всё угробит. А ORM вносит допонительную магнитуду неопределенности в размещении данных.

Поэтому и появляются такие вещи как BigTable, MapReduce и Eventually Consistent. Вот туда сейчас вектор направлен. RDBMS - уже вчерашний день, хотя жить будет еще очень-очень долго.

aist1 ★★★
()
Ответ на: комментарий от Absurd

так до чего в итоге договорились то? я делаю так:

class Persistable implements Serializable {
  Long id; //геттеры и сеттеры соответственно
}

interface PersistanceService<T extends Persistable> {
  public T update(T obj);
  public T findByPrimaryKey(Long id);
  public List<T> findAll();
  public List<T> findAll(int startRow, int count);
  public void remove();
}

abstract class PersistableServiceImpl<T extends Persistable> implements PersistableService<T> {
  ...
  public abstract Class<T> getPersistableClass();
}

class Foo extends Persistable {
  String name;
}

interface FooService extends PersistableService<Foo> {

  //здесь бизнес-логика касательно Foo, например заFooячить все туда-то
}

class FooServiceImpl extends PersistableServiceImpl<Foo> implements FooService {
  public Class<Foo> getPersistableClass() {
    return Foo.class;
  }
}

class SomeLogicService { //например, JSF Managed бин
   FooService fooService;
}

то есть смешиваются DAO и бизнес логика, но на уровне кода на это наплевать, потому как все наследуется от PersistableService и база DAO в сервисах не фигурирует. Ну и финал:

<tx:advice id="txAdvice" transaction-manager="transactionManager">
  <tx:attributes>
    <tx:method name="get*" propagation="SUPPORTS"/>
    <tx:method name="find*" propagation="SUPPORTS"/>
    <tx:method name="*" propagation="REQUIRED"/> 
  </tx:attributes>
</tx:advice>
<aop:config> 
  <aop:advisor pointcut="execution(* *Service.*(..))" advice-ref="txAdvice"/>                                                    
</aop:config>

получается все не верно?

Deady
()
Ответ на: комментарий от dizza

>Видели кода-нибудь SQL-запрос длиной в 300-400 строк?

Видели когда-нибудь сайт www.google.com? А в нем "внутри" вообще РСУБД нет и соответственно запросов по 300 строк. И поэтому ничего не тормозит, вот бы все такие программы писали

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Deady

> <tx:method name="get*" propagation="SUPPORTS"/>
> <tx:method name="find*" propagation="SUPPORTS"/>


Может, тут ещё read-only="true" поставить? :)

Bohtvaroh ★★★★
()
Ответ на: комментарий от Karapuz

> Видели когда-нибудь сайт www.google.com? А в нем "внутри" вообще РСУБД нет и соответственно запросов по 300 строк. И поэтому ничего не тормозит, вот бы все такие программы писали

Так там индексы строятся, это типа lucene, только покруче. )) Там своих заморочек хватает. И вообще РСУБД у гугла где-то да 100% используются.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

Бррр, это я к тому, что утверждение "в нем "внутри" вообще РСУБД нет и соответственно запросов по 300 строк. И поэтому ничего не тормозит" это полная чушь в контексте поисковика.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Hjorn

> А джависты тем временем продолжают жевать кактус pure OOP, ещё и нахваливают.

Во-первых, речь о Scala, а не о Java.

Во-вторых, в Scala основной парадигмой является функциональная, хотя язык и является полноценным ООП-языком. Как написал сам автор, смысл в том, чтобы выращенные на ООП-only языках программисты могли переучивать постепенно.

В-третьих, это самый злостный оффтопик, который я когда-либо видел в комментах на ЛОРе. Новость про аналог LINQ для Scala, а обсуждение какого-то хибернейта и джавы - всё это имеет весьма опосредованное отношение к теме.

voronaam ★★
()
Ответ на: комментарий от voronaam

> это самый злостный оффтопик, который я когда-либо видел в комментах на ЛОРе.

Ой, да ладно? Весь ЛОР - это злостный оффтопик, тем и ценен ;)

Hjorn
()
Ответ на: комментарий от Karapuz

>Видели когда-нибудь сайт www.google.com? А в нем "внутри" вообще РСУБД нет и соответственно запросов по 300 строк.

Ну Том Кайт где-то писал что сущестуют инсталляции Оракла и DB2 где объем хранимых и запрашиваемых данных составляет порядка одного экзабайта.

Absurd ★★★
()
Ответ на: комментарий от Karapuz

тормозы и не поняли, что такое LINQ

А что такое LINQ?

Language Integrated Query Совсем не SQL, как эти тормозы подумали. Предложения выглядят несколько SQL подобно, но это побочный эфект. Более того, так как SQL какправило в хранимых процедурах, то толку от linq2sql почти никакого. Разве что nhibernate переписать чтобы поприкольнее выглядело.

Благодаря LINQ можно писать нормальный лямбда выражения.

arr.Where(x => x > 1 && x<8).Sum()

А основное - это работа со списками

IEnumerable<int> query = from x in array
                         where x % 2 == 1
                         orderby x descending
                         select x * x;
выглядит читабельнее чем
IEnumerable<int> query = array.Where(x => x % 2 == 1).OrderByDescending(x => x).Select(x => x * x);

grim ★★☆☆
()
Ответ на: комментарий от Bioreactor

>Понятно. Агенство "О.Б.С."

Проскакивало на лоре - обозначет ссылки ищи там. Но ты продолжай.

>И что? Это "история успеха" ?

Это ответ на твой вопрос подтвержденній ссылкой.

>Это не обоснование, а поток сознания. Аргументация проводится на конкретных примерах.

Зато ваши контраргументы - поражают.

>Ой-вей, Б-же мой, а Вы-таки уже врач с дипломом психиатора, раз диагноз устанавливаете?

А вы не согласны?

>Да, pure-OODBMS Cache эффективней, однако, имеет свой собственный формат и имеет ограниченное число заказчиков.

Я конечно понимаю что в наш век высоких технологий и заброшенных лунных программ писать в файлы западло, а разрабатывать фреймворки умеют только инопланетяне, потому что такой орган как моз хомо сапиену оказался ни к чему....

r ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Интересно, взгляну. Они там сделали что-то для писания своих оптимизаторов запросов?

То было когда деревья были очень большими. Что там счас уже не представляю совсем.

r ★★★★★
()
Ответ на: комментарий от Bioreactor

>"SessionFactory может поддерживать опциональный кэш для данных, которые используются несколькими транзакциями, этот кэш называют кэш второго уровня (second-level cache) или кэш уровня JVM (JVM-level cache). Данный кэш можно настроить таким образом чтобы он работал как для одного процесса (process-level) так и для нескольких процессов в кластере (cluster-level). " (с)

"Слов ты много выучил" (C).... и что? Кэш нужен чтобы гибернейту не обращаться к базе данных за объектами в случае когда он их уже поднял в соседней сессии по такому-же запросу и не делать много работы второй раз. В результате чего в случае кластера когда данные меняются из другой систему (соседний сервер) помимо текущего гибернейта возникает необходимость в механизме синхронизации этих кэшей, потому что после первого же такого паралленльного изменения в кэшах - мусор. То есть транзакционный кэшь это не божий дар - а единственный вариант работы гибернейта в кластере - вынужденная мера. Ну или отключить его к хренам. О чем я и говорю.

r ★★★★★
()
Ответ на: комментарий от dizza

Или это мой параноидальный бред?

А проверить?

con1:

test=# set transaction isolation level repeatable read;
SET
test=# begin;
BEGIN
test=# select * from test;
 a |        b
---+------------------
 3 | a3
 1 | updated 11111
 2 | updated 222sss-1
(3 rows)

con2:
test=# select * from test;
 a |        b
---+------------------
 3 | a3
 1 | updated 11111
 2 | updated 222sss-1
(3 rows)

con1:
test=# update test set b='x' where a = 3;
UPDATE 1
test=# select * from test;
 a |        b
---+------------------
 1 | updated 11111
 2 | updated 222sss-1
 3 | x
(3 rows)


con2:

test=# select * from test;
 a |        b
---+------------------
 3 | a3
 1 | updated 11111
 2 | updated 222sss-1
(3 rows)

con1:

test=# commit ;
COMMIT

con2:

test=# select * from test;
 a |        b
---+------------------
 1 | updated 11111
 2 | updated 222sss-1
 3 | x
(3 rows)

postgresql.
r ★★★★★
()
Ответ на: комментарий от voronaam

А они хотят по другому
val megaCorpEmps = for {
p <- underAge
if p.company.name is "MegaCorp"
} yield p

И еще,

Of all of the projects in this field, HaskellDB [6] is likely the most similar to our approach in that it functions as an internal domain-specic language. Operations such as filter, join and conditionals are all supported in a statically checked, type safe environment provided by Haskell's type system. The AraRat [5] framework provides similar functionality in C++ through the use of preprocessor directives, operator overloading and templates.

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Karapuz

>А они хотят по другому

Это не потому что они именно так хотят, это потому как именно компилятся for comprehensions. Все что можно реализовать с помощью "семантики" map, flatMap и filter можно запихнуть в синтаксис for скалы. Семантика в кавычках потому, что туда что угодно запихнуть можно включая блекджек. Абы нэйминг конвеншен.

r ★★★★★
()
Ответ на: комментарий от grim

IEnumerable<int> query = from x in array
where x % 2 == 1
orderby x descending
select x * x;


IEnumerable<int> query = array.
Where(x => x % 2 == 1).
OrderByDescending(x => x).
Select(x => x * x);

Ну вот. Теперь второе так же читабельно как и первое

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Karapuz

я бы не сказал, что такое-же
Кроме того без нормальных лямбда выражений Where дожно выглядеть как
Where(bool delegate(int x) { return x % 2 == 1; })

а без делегатов, отсутствующих к примеру, в Java придётся изголяться через анонимные класы.
ХЗ, как дело обстоит в Склале

grim ★★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.