а может разбить на два запроса как-то

У тебя "А джоин Б где поле не что-то"

В зависимости от типа джоина варируется результат

у меня left_join

это, если я правильно помню все A + принадлежащие им B

у меня left_join

А нужен right или inner

нет )

нужен левый )

просто через where он отсеивает там где B == NULL

а ему надо B.fields == NULL

это, если я правильно помню все A + принадлежащие им B

Да, но будут нулловые поля, где не будет найдено соответствие по условию

inner наоборот отсеет все A без B

нужен левый )

Нулл же будет

Короч, берешь какое то поле

A right вернет мне кучу B

По которому делаешь обратное условие.

например B.id != NULL

А ему отсеять А нужно в зависимости от полей в Б

Должно сработать я думаю.

И это вроде не лефт

вот я щас дрочу запрос, который имеет 174 строчки

а вы left от right join'a не можете отличить

Но у меня уже мозги киснут ?

Короче, давайте примем за истину, что я не накосячил с типом join

потому что это так

давай ты просто напишешь отношения между таблицами и что тебе нужно

и я тебе напишу обычный sql

без orm'a

И это вроде не лефт

Лефт это все A и B != NULL

вот я щас дрочу запрос, который имеет 174 строчки

"я страдаю — и вы страдайте"

я не страдаю

люблю sql

Лефт это все A и B != NULL

Ну так нужно же отсечь А, не?

люблю sql

большинство не любят sql, ты им подлянку делаешь

Но мы конечно же думаем только о себе.

постгрес такой мощный пиздец

Ну так нужно же отсечь А, не?

ему нужно отсечь A где B.fields{} != NULL

ему нужно отсечь A где B.fields{} != NULL

И это вроде не лефт

и я тебе напишу обычный sql

A has_one B. Нужно вернуть все A где A.B == null || A.B.field != null

SELECT * FROM A LEFT JOIN B ON B.ID = A.B_ID WHERE B.ID IS NULL UNION SELECT * FROM A INNER JOIN B ON B.ID = A.B_ID WHERE B.FIELD IS NOT NULL

Еще раз А и Б (сидели на трубе) Нужно вернуть все А 1) У которых - B не равны нулю определенные поля 2) все записи А у которых нет принадлежащей B

union это два внутренних запроса, не?

зачем так жить

SELECT * FROM A LEFT JOIN B ON B.ID = A.B_ID WHERE B.ID IS NULL UNION SELECT * FROM A INNER JOIN B ON B.ID = A.B_ID WHERE B.FIELD IS NOT NULL

UNION!

юнион охуенная штука

Боже, спасибо, я и забыл уже про этого мерзавца

не помню умеет AR в OR или нет.

нахуй натягивать сову на глобус если можно сделать нормально

Еще раз А и Б (сидели на трубе) Нужно вернуть все А 1) У которых - B не равны нулю определенные поля 2) все записи А у которых нет принадлежащей B

верно

union это два внутренних запроса, не?

бд все равно оптимизирует и выполняет один

вообще постгресу например похуй на сложность запроса

если там внутренние селекты и проч

ну важно не только сложность запроса, а размер бд.

если 1-2 млн записей то ему тоже похуй

2.3.1 (app)[18] » [3.years.to_i, 36.months.to_i] => [94672800, 93312000] 2.3.1 (app)[19] » 3 * 12 => 36

Бредово как то

Где я тут ошибся?

Где я тут ошибся?

високосные?

в трех годах?

в трех годах?

а?

ну не факт что в трех годах будет один високосный год

надо смотреть в соус ActiveSupport::Duration.to_i

тут дело в количестве дней в месяце похоже

в трех годах?

в последних трёх был, он может относительно текущей даты смотрит

ERROR: S client not available

тут дело в количестве дней в месяце похоже

мб тоже

а может и сумма этого

12.month.to_i это 30.days.to_i * 12, а не 365.days.to_i активсаппорт не такой умный =)

он месяцы по 30 дней считает

2.3.0 :181 > 12.months == 1.year => false

2.3.0 :184 > 365.days == 1.year => false

life == good => false

последнее меня смущает)

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

чем 365.days отличаются от 1.year?

там какие нибудь замуты с датами опять.

разница в 6 часов почему-то

похоже это связано с високосными годами

накапливается погрешность по 6 часов в год

и за 4 года получаем одни сутки дополнительные

а точняк

поправте, если я что-то не так понял. блоки и проки выполняются там, где были обьявлены, а методы там, в каком контексте были вызваны. верно?

поправте, если я что-то не так понял. блоки и проки выполняются там, где были обьявлены, а методы там, в каком контексте были вызваны. верно?

Вряд ли. Тебя сложно понять

Там есть лямды и проки

При вызове p (where p - Proc.new{}) возвращается место в памяти, lamda также только + пометка lambda

Разница при испольнение keyword return Proc возвращается к коду от куда был вызван Lambda возвращает код сразу же за пределами lambda кода

Почему возвращает false, а в переменной true? var = true and false => false var => true

потому что (var = true) and false, очевидно

аа, потому что приоритет and даже выше чем = ?

аа, потому что приоритет and даже выше чем = ?

Наоборот

у && выше, а у and ниже.

Не используйте and/or

Просто не используйте

Также как и not