@Dolfik Поясни.

let a = "blablabla" printf a

printf "%s" a

Блин, точно)

Я хочу несколько условий вынести, потому что они дофига комплексные, и использовать в нескольких запросах. Условные джойны хочу, условный order by.

вот я тоже тут проблем не вижу если делать внутри query{...}

Ну так это делается с iqueryable оч хорошо.

Неа, не делается. Вот пример (на C#): Expression<Func<User, bool>> a, b ,c; Users.AsQueryable().Where(u => a(u) && b(u) && c(u)); // не скомпилируется: у Expression<T> нет оператора круглых скобок

Неа, не делается. Вот пример (на C#): Expression<Func<User, bool>> a, b ,c; Users.AsQueryable().Where(u => a(u) && b(u) && c(u)); // не скомпилируется: у Expression<T> нет оператора круглых скобок

Ты что-то не то делаешь

вот я тоже тут проблем не вижу если делать внутри query{...}

А что именно делать внутри query? Как мне часть запроса вынести в переменную? (Просто, ну, я и правда могу чего-то не знать — может, там есть такая фича)

А что именно делать внутри query? Как мне часть запроса вынести в переменную? (Просто, ну, я и правда могу чего-то не знать — может, там есть такая фича)

У тебя users уже должны быть queriable а не материализованными данными.

У тебя users уже должны быть queriable а не материализованными данными.

Это как минимум

У тебя users уже должны быть queriable а не материализованными данными.

Я для примера показал. Всё равно не скомпилируется.

А так блин

Ты что-то не то делаешь

Я делаю то, что всегда делаю: пишу программу, вынося кусочки (частично применённые функции и что угодно ещё) в переменные. Да, с SQL оно так просто не работает. Нет, ограничение это не фундаментальное, и его можно решить.

Я делаю то, что всегда делаю: пишу программу, вынося кусочки (частично применённые функции и что угодно ещё) в переменные. Да, с SQL оно так просто не работает. Нет, ограничение это не фундаментальное, и его можно решить.

Я не про подход. Идея то нормальная и я Ее использовал в iqueriable

Я про код

Решается ли это в рамках текущих или будущих технологий F#, и такая ли уж это нужная фича — вопрос дискуссионный.

Мне на каждом проекте приходится решать эти вот проблемы программируемых запросов. Где-то более успешно, где-то менее. Кое-где даже строки конкатенируем, и это ужас-ужас :)

Для EF и System.Linq.Expressions я себе решение наколдовал, кстати, но оно мне не очень нравится — в промышленных масштабах не поиспользуешь. Если бы F#, например, давал возможность типобезопасно композировать кусочки запросов, то на .NET-стеке это бы точно было киллер-фичей для некоторых проектов.

(и у меня нет уверенности, что сделать такое на сегодняшнем F# невозможно — можно и попробовать)

А что именно делать внутри query? Как мне часть запроса вынести в переменную? (Просто, ну, я и правда могу чего-то не знать — может, там есть такая фича)

вот они показывают как комозить запросы. Так пойдёт? https://fsprojects.github.io/SQLProvider/core/composable.html

Решается ли это в рамках текущих или будущих технологий F#, и такая ли уж это нужная фича — вопрос дискуссионный.

Во, код писать не могу, но помню что пример был у бындю http://blog.byndyu.ru/2014/07/command-and-query-responsibility.html?m=1

здесь пример как трансформировать вручную : http://stackoverflow.com/questions/42583018/sqlprovider-recursively-composing-queries

вот они показывают как комозить запросы. Так пойдёт? https://fsprojects.github.io/SQLProvider/core/composable.html

Пойдёт, но частично. Это композируемость примерно того же уровня, что и в EF. Она не решает, например, вышеприведённой проблемы с a(u) && b(u) && c(u).

Для EF и System.Linq.Expressions я себе решение наколдовал, кстати, но оно мне не очень нравится — в промышленных масштабах не поиспользуешь. Если бы F#, например, давал возможность типобезопасно композировать кусочки запросов, то на .NET-стеке это бы точно было киллер-фичей для некоторых проектов.

http://fsprojects.github.io/SQLProvider/core/composable.html

Пойдёт, но частично. Это композируемость примерно того же уровня, что и в EF. Она не решает, например, вышеприведённой проблемы с a(u) && b(u) && c(u).

Видимо ты так и не донёс до меня проблему

Видимо ты так и не донёс до меня проблему

Ну вот же проблема: есть три экспрешена, a, b и c. Надо выбрать из базы объекты, которые отвечают выражению User u => a(u) && b(u) && c(u).

Пойдёт, но частично. Это композируемость примерно того же уровня, что и в EF. Она не решает, например, вышеприведённой проблемы с a(u) && b(u) && c(u).

а почему не пойдёт-то? внутри where тебе доступны же сущности любого из твоих запрсов.

а почему не пойдёт-то? внутри where тебе доступны же сущности любого из твоих запрсов.

Ну скажи, как записать решение задачки.

Это решается. Я буду к компа напишу.

Мне и правда интересно, как другие предложат её решить, в особенности с помощью SQLProvider, с которым я не очень хорошо знаком.

@fvnever а как насчёт этого: http://fsprojects.github.io/FSharp.Linq.ComposableQuery/ ? Правда, лично пока ещё не пробовал.

@fvnever а как насчёт этого: http://fsprojects.github.io/FSharp.Linq.ComposableQuery/ ? Правда, лично пока ещё не пробовал.

Да, вот это уже похоже! Надо изучить подробнее.

Странно только ,что относительно долго не обновляется.

Предположу, что мало кому нужны настолько сложные запросы, поэтому пользователей мало, и поток issues тоже небольшой.

Ну вот же проблема: есть три экспрешена, a, b и c. Надо выбрать из базы объекты, которые отвечают выражению User u => a(u) && b(u) && c(u).

А напиши плз реализацию a(u)

Например

Предположу, что мало кому нужны настолько сложные запросы, поэтому пользователей мало, и поток issues тоже небольшой.

Ну раз кто-то готов строки конкатенировать, то, похоже, нужны. ?

А напиши плз реализацию a(u)

Пусть будет так: Expression<Func<User, bool>> a = u => u.Id != Guid.Empty;

@Dolfik телеграм обновил API)

@Dolfik телеграм обновил API)

Я видел)

Пока блин времени нет заниматься библиотекой :(

Нуок

Artemy @fvnever А ведь про ComposableQuery как раз в том видео с Вадлером говорится. :)

Ок, я эту библиотечку посмотрю.

а нельзя что-то типа a(b(c(Users))), где a, b, c эти users.Where(u => u.Id != Guid.Empty) ?

а нельзя что-то типа a(b(c(Users))), где a, b, c эти users.Where(u => u.Id != Guid.Empty) ?

Да, можно, но это работает только для варианта && :)

@fvnever И видео!

Если хочется a || b || c — тогда уже фейл.

а, ну да

@gsomix да, действительно. Спасибо за видео, схоронил. :)

При запуске F# аппы: System.TypeInitializationException was unhandled Message: An unhandled exception of type 'System.TypeInitializationException' occurred in DumpsDownloader.exe Additional information: Инициализатор типа "<StartupCode$DumpsDownloader>.$Program" выдал исключение.

А какое исключение-то? :)

А напомните почему в F# нет “Optional function arguments”? Сейчас узнал что они есть в OCaml и SML Кстати, прикольное сравнение языков http://adam.chlipala.net/mlcomp/

@angmarr > We decided against this in F# 2.0/3.0. There were good reasons for this: among other things, the OCaml syntax is unwieldy when there is a fair amount of object/member programming going on as well.

Это про named arguments, но optional там рядом.

@angmarr В SML же тоже нету.

@angmarr В SML же тоже нету.

Блин точно, там в примере через Option сделано (интересная замена ?)

А какое исключение-то? :)

Вот скинул выше всё, что возникает

Вот скинул выше всё, что возникает

Чот не оч! Давай дебаг тогда.

Settings.Load("settings.json")

Из за этого

type Settings = JsonProvider<""" { "dumpsPathOnServer":"/home/dumps", "saveToLocal":"C:/db-dumps", "serverAddress": "localhost", "serverPort":22, "serverLogin":"root", "serverPassword":"password" } """>

Или Settings.Load это не загрузка из JSON файла, а что-то другое?)

Не пойму, как с помощью Json Provider'a распарсить файл. Если файл до запуска существует, то всё ок, иначе падает

Не пойму, как с помощью Json Provider'a распарсить файл. Если файл до запуска существует, то всё ок, иначе падает

В смысле "до запуска существует"?

Падает, если файла не существует даже во время компиляции?

В смысле "до запуска существует"?

Settings.Load("settings.json") Выбрасывает исключение при запуске, если settings.json не существует (до выполнения этого кода)

Падает, если файла не существует даже во время компиляции?

Нет, не во время компиляции

ERROR: S client not available

@Dolfik Справку по Load читал?

После запуска, но до выполнения кода

@Dolfik Справку по Load читал?

В описании метода написано: Loads JSON from specified URI

Я так понимаю, оно и должно просто парсить файл.

Непонятно, как оно определяет существование файла до того, как этот код сработает.

А как быть, если файла нет?

У меня перед этим кодом стоит проверка, если файла нет, он создаётся

Ну он ведь есть к тому моменту, когда Load вызывается?

Но не прокатывает)

@Dolfik Ты уверен, что он создается там, где надо?

Ну он ведь есть к тому моменту, когда Load вызывается?

Когда приложение запускается - файла нет, перед вызовом Settings.Load, файл создаётся, если его нет

Можешь поставить бряк до Load?

Можешь поставить бряк до Load?

Да, не попадает туда

@Dolfik, точно создаётся?

Вообще даже на первую строчку кода не попадает

Короче, это странно немного

Ну, чисто логически: как можно узнать о том, что файла нет до того, как осуществляется запрос к нему?

Так что, видимо, файла просто нету к моменту вызова Load

http://stackoverflow.com/questions/33630308/f-xml-provider-system-typeinitializationexception-when-writing

@Dolfik Проверь еще раз пути, и все такое.

И покажи, пожалуйста, код целиком.

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

А это происходит при инициализации класса. Помнишь, что модули компилируются в классы?

Блин, ошибка в другом была)

Щас покажу интересную штуку

type Settings = JsonProvider<""" { "test":"test" } """> let notUsed = Settings.GetSample().JsonValue.AsString() [<EntryPoint>] let main argv = printf "Application started.\nParsing settings..." 0 // return an integer exit code

При запуске получаешь System.TypeInitializationException

Пока не закомментишь строку let notUsed = ...

втф?

Ошибка во время инициализации класса.

Сделай из notUsed функцию и вызови в main.

Блин, точно, я идиот :D