Вы в этом уверены? Карму ведь не только минусуют, но еще и плюсуют — и тоже интересно кто плюсовал.
У меня как то был случай, написал человеку резко (но не грубо) и даже за дело. Он мне поставил минус в карму. Что это он, определил по косвенным признакам. Написал в личку, типа того:
— ты зачем типа меня не взлюбил?
— ну а ты чего…
в общем слово за слово, разговорились и нашли общий язык и взаимопонимание (товарищ даже передумал и вернул карму на место, а я так и не минусовал ему в ответ вовсе). Это приятно, и ему судя по всему тоже. Иногда люди просто не понимают друг друга. Если к карме относится не с точки зрения рейтингов, а с точки зрения того, что это показатель отношения к тебе людей — то очень бы хотелось знать кто и за что против тебя или испытывает к тебе негатив.
Хотя чего это я… откуда склонность к утопическим идеям… наверно вот этим топиком навеяло :)
p.s. как вариант — позволить человеку выбрать — хочет ли он, что бы тот кому он меняет карму знал кто это сделал или хочет остаться анонимным.
Мне наверно повезло (или наоборот) — но я не прочитал ни одного документа, посвященного стандартам кодирования, и ни разу не попал в команду с устоявшимися стандартами, так что мои вкусы — результат личной практики, ну и что-то где-то бессознательно впитал на чужих примерах :)
Для запросов без форматирования есть несколько причин — тут не очень дружелюбный парсер, имхо. Понять как он работает, и что и когда выкусывает — можно только после некоторой практики, но после пары использований лично у меня было желание им больше не пользоваться. К тому же о том, что тут есть такие возможности лично я как то даже и не сразу заметил (+где то вроде натыкался, что html-тэги доступны только выше некоторого количества кармы, может ошибаюсь).
Ну и потом наверно многим лень этим заниматься.
Кстати не все запросы требуют форматирования. Запросы вида «SELECT name FROM obj_types» я, например, часто так и пишу в одну строку, ибо они слишком просты.
Ну во первых, как уже сказали — для красоты :)
Но это не самое главное. Представьте себе ситацию, у нас есть функиция, в которой запрос генерится исходя из переданных ей параметров, например (опять же пример от балды, только для демонстрации)
SELECT ... FROM ...
WHERE
if(def condition1){ f1='condition1' }
if(def condition2){ f2='condition2' }
тут видно, что будет ошибка, т.к. в момент первой проверки, мы не знаем результат второй, и поэтому не можем поставит AND после нее. Во стором условии мы не знаем результат первого, поэтому не можем поставить вначале. Более того, если не выполится ни одно их них — то мы получим ошибку синтаксиса из-за пустого WHERE. Эти проблемы можно решить кучей дополнительных if-ов, количество и громоздкость которых будет увеличиваться от количества условий. А можем решить по простому:
SELECT ... FROM ...
WHERE 1=1
if(def condition1){ AND f1='condition1' }
if(def condition2){ AND f2='condition2' }
Тут никаких доп. проверок делать не надо, и если не будет задано ни одного условия, то ошибки тоже не произойдет. Причем если мы уже сгенерированный запрос кладем для анализа в лог — то там мы увидим вполне красиво отформатированный запрос. Что же касается MySQL — то он это выражение 1=1 попросту отбросит, потому что оно всегда true.
Поскольку заранее не всегда ясно будет ли этот запрос динамическим или не будет — я приучил себя писать 1=1 всегда.
А в чем собственно проблема, следуем тем же принципам:
SELECT
t.field,
t.field1,
...
FROM
( SELECT
t_in.field,
t_in.field1,
...
FROM t_in
WHERE t_in.id = 100
GROUP BY t.field
ORDER BY t.field
) AS tbl_in
INNER JOIN table1 t1 ON t1.id=t.id
INNER JOIN table2 t2 ON t2.id=t1.id
WHERE 1=1
AND t.value='foo'
AND t1.value='bar'
GROUP BY t.field
ORDER BY t.field
К сожалению tab внутри pre разносит сильно вширь, поэтому поменял на nbsp, в редакторе удобнее конечно использовать табуляцию (хотя обять же это дело вкуса)
смысл самого запроса нулевой — только для демки форматирования.
Не уверен, что для такого вопроса надо было делать целый топик..., но скажу про свои «вкусы»
я привык, что всегда строка начинается с ключевого слова (подобно FROM или ORDER BY), а группировка основных секций-блоков идет с помощью отсутпов. + ON не выделяется отдельно а идет вместе с JOIN (ибо неразрывно с ним связан), т.е. мой вариант такой:
SELECT
t.field,
t.field1,
...
FROM tbl t
INNER JOIN table1 t1 ON t1.id=t.id
INNER JOIN table2 t2 ON t2.id=t1.id
WHERE 1=1
AND t.value='foo'
AND t1.value='bar'
GROUP BY t.field
ORDER BY t.field
Но не навязываю и ни к чему призываю, само собой..., дело вкуса :)
Можно использовать UDF (user defined function), вызываемую из триггера, удаляющую или обновляющую файл (локально или на удалённом сервере) при изменении записей в таблице. Это возможно.
вся ветка — обсуждение данной возможности, с учетом собственно темы топика. Вы же зацепились не понятно зачем, конкретно за триггеры, и продолжаете упорствовать :)
сначала идет список обязательных требований для кредита, потом форма, в которой первые шесть пунктов, есть реинкарнация вышеперечисленных требований. Типа, ну если вы такой тупой — давайте мы вам с помощью формы все повторим, бред чистой воды. Вся форма сводится к двум последним полям, работающим по хитрому алгоритму, хотя легче было бы словами описать это единственное не перечисленное в списке требование :)
Очень порадовало, что логотип в ЛВУ, традиционно ведущий на главную страницу, почему то на странице формы ведет… на страницу формы, хотя на других работает как положено :)
то что не дают выбрать между виртуальной клавой и обычной — может и правильно, в конце концов это же для вашей безопасности. Другое дело реализация, тут да — не ахти.
А вообще конечно много мелких косяков, но бывает гораздо хуже. Напишите им в саппорт — глядишь чего нибудь и подправят.
Блин, иногда вместо моей картинки показывается вообще хрен знает что, причем иногда полный бред. не бейте меня — это видно какие-то проблемы на dump.ru или они так специально делают :(
Пора хабру, имхо, сделать какое-нибудь своё простейшее хранилище файлов пользователей…
смущает, да… про это я забыл, пока писал эти строки, вы уже тоже написали.
так что прошу прощения за свою ошибку, вы были правы, а я прочитал невнимательно.
ну чтож, тем смешнее, хром имеет такой же баг как ie, мда…
Да если бы… просто на taptaptap что то поменяли. Видимо баг проявляет себя в определенных условиях, так как у меня на чистом фоне просто png-картинка отображается нормально. При каких, конкретно, условиях проявляется баг — я честно говоря не знаю, не ковырял еще.
Вот из той же заметки ссылка. Прокрутите вниз до комментариев — видите слева от каждого серые прямоугольники? Сравните с FF, например (в IE тоже можно увидеть разницу, но в 7-ке расползается там всё).
Ну раз пошла такая пьянка, напишу, чем меня очень расстроил хром.
1. неправильно отображает png. Я, честно вам скажу, господа — я в шоке. В условиях когда уже всеми нелюбимый IE научился показывать png, от Хрома я такого не ожидал никак. Даже не смотря на то, что он beta.
2. похоже что по производительности он достаточно скоро уйдет с завидного первого места. Неоднократно хром закрывается на моей, достаточно шустрой машинке по 20-30 секунд (при большом количестве вкладок). Наверно это как то связано с тем, что каждая вкладка — отдельный процесс, не знаю. Но очень неприятно. Что будет, когда появятся расширения — пока даже представить не могу, но подозреваю что лучше не станет.
Вот так… в остальном он мне очень нравится пока, сейчас вот в нем этот комментарий пишу :)
Ммм… а я где то писал про опасность использования триггеров?
Я лишь сказал, что небезопасно вешать удаление файлов на удаление записи в БД ибо в случае ошибки в скриптах, злоумышленник сможет грохнуть не только записи в таблицах БД (которую можно бэкапить), но и всё файло с ней связанное. По моему вы изначально меня неправильно поняли.
У меня как то был случай, написал человеку резко (но не грубо) и даже за дело. Он мне поставил минус в карму. Что это он, определил по косвенным признакам. Написал в личку, типа того:
— ты зачем типа меня не взлюбил?
— ну а ты чего…
в общем слово за слово, разговорились и нашли общий язык и взаимопонимание (товарищ даже передумал и вернул карму на место, а я так и не минусовал ему в ответ вовсе). Это приятно, и ему судя по всему тоже. Иногда люди просто не понимают друг друга. Если к карме относится не с точки зрения рейтингов, а с точки зрения того, что это показатель отношения к тебе людей — то очень бы хотелось знать кто и за что против тебя или испытывает к тебе негатив.
Хотя чего это я… откуда склонность к утопическим идеям… наверно вот этим топиком навеяло :)
p.s. как вариант — позволить человеку выбрать — хочет ли он, что бы тот кому он меняет карму знал кто это сделал или хочет остаться анонимным.
Для запросов без форматирования есть несколько причин — тут не очень дружелюбный парсер, имхо. Понять как он работает, и что и когда выкусывает — можно только после некоторой практики, но после пары использований лично у меня было желание им больше не пользоваться. К тому же о том, что тут есть такие возможности лично я как то даже и не сразу заметил (+где то вроде натыкался, что html-тэги доступны только выше некоторого количества кармы, может ошибаюсь).
Ну и потом наверно многим лень этим заниматься.
Кстати не все запросы требуют форматирования. Запросы вида «SELECT name FROM obj_types» я, например, часто так и пишу в одну строку, ибо они слишком просты.
дайте уже и другим такую возможность :)
Но это не самое главное. Представьте себе ситацию, у нас есть функиция, в которой запрос генерится исходя из переданных ей параметров, например (опять же пример от балды, только для демонстрации)
SELECT ... FROM ... WHERE if(def condition1){ f1='condition1' } if(def condition2){ f2='condition2' }тут видно, что будет ошибка, т.к. в момент первой проверки, мы не знаем результат второй, и поэтому не можем поставит AND после нее. Во стором условии мы не знаем результат первого, поэтому не можем поставить вначале. Более того, если не выполится ни одно их них — то мы получим ошибку синтаксиса из-за пустого WHERE. Эти проблемы можно решить кучей дополнительных if-ов, количество и громоздкость которых будет увеличиваться от количества условий. А можем решить по простому:
SELECT ... FROM ... WHERE 1=1 if(def condition1){ AND f1='condition1' } if(def condition2){ AND f2='condition2' }Тут никаких доп. проверок делать не надо, и если не будет задано ни одного условия, то ошибки тоже не произойдет. Причем если мы уже сгенерированный запрос кладем для анализа в лог — то там мы увидим вполне красиво отформатированный запрос. Что же касается MySQL — то он это выражение 1=1 попросту отбросит, потому что оно всегда true.
Поскольку заранее не всегда ясно будет ли этот запрос динамическим или не будет — я приучил себя писать 1=1 всегда.
К сожалению tab внутри pre разносит сильно вширь, поэтому поменял на nbsp, в редакторе удобнее конечно использовать табуляцию (хотя обять же это дело вкуса)
смысл самого запроса нулевой — только для демки форматирования.
я привык, что всегда строка начинается с ключевого слова (подобно FROM или ORDER BY), а группировка основных секций-блоков идет с помощью отсутпов. + ON не выделяется отдельно а идет вместе с JOIN (ибо неразрывно с ним связан), т.е. мой вариант такой:
Но не навязываю и ни к чему призываю, само собой..., дело вкуса :)
вся ветка — обсуждение данной возможности, с учетом собственно темы топика. Вы же зацепились не понятно зачем, конкретно за триггеры, и продолжаете упорствовать :)
— тогда блок можно класть на любой фон, а не только на белый. Проверено в IE7/FF3/Safari. В остальных тоже должно по идее работать.
сначала идет список обязательных требований для кредита, потом форма, в которой первые шесть пунктов, есть реинкарнация вышеперечисленных требований. Типа, ну если вы такой тупой — давайте мы вам с помощью формы все повторим, бред чистой воды. Вся форма сводится к двум последним полям, работающим по хитрому алгоритму, хотя легче было бы словами описать это единственное не перечисленное в списке требование :)
то что не дают выбрать между виртуальной клавой и обычной — может и правильно, в конце концов это же для вашей безопасности. Другое дело реализация, тут да — не ахти.
А вообще конечно много мелких косяков, но бывает гораздо хуже. Напишите им в саппорт — глядишь чего нибудь и подправят.
Пора хабру, имхо, сделать какое-нибудь своё простейшее хранилище файлов пользователей…
так что прошу прощения за свою ошибку, вы были правы, а я прочитал невнимательно.
ну чтож, тем смешнее, хром имеет такой же баг как ie, мда…
Код при этом тривиальный:
А насчет того, что у хрома проблемы c png+opacity вы правы, спасибо.
И где у IE проблемы с opacity?
Вот из той же заметки ссылка. Прокрутите вниз до комментариев — видите слева от каждого серые прямоугольники? Сравните с FF, например (в IE тоже можно увидеть разницу, но в 7-ке расползается там всё).
Хром, ессно, у меня последний.
Либо приведите пример, а то я может чего пропустил
1. неправильно отображает png. Я, честно вам скажу, господа — я в шоке. В условиях когда уже всеми нелюбимый IE научился показывать png, от Хрома я такого не ожидал никак. Даже не смотря на то, что он beta.
2. похоже что по производительности он достаточно скоро уйдет с завидного первого места. Неоднократно хром закрывается на моей, достаточно шустрой машинке по 20-30 секунд (при большом количестве вкладок). Наверно это как то связано с тем, что каждая вкладка — отдельный процесс, не знаю. Но очень неприятно. Что будет, когда появятся расширения — пока даже представить не могу, но подозреваю что лучше не станет.
Вот так… в остальном он мне очень нравится пока, сейчас вот в нем этот комментарий пишу :)
Я лишь сказал, что небезопасно вешать удаление файлов на удаление записи в БД ибо в случае ошибки в скриптах, злоумышленник сможет грохнуть не только записи в таблицах БД (которую можно бэкапить), но и всё файло с ней связанное. По моему вы изначально меня неправильно поняли.