|
|
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Нужен совет Имеем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Теперь, когда делаю выборку вида Код: plaintext 1. Запрос с условием по любому отдельному классу тоже отрабатывает как надо: Код: plaintext 1. Код: plaintext 1. select t1.id, t2.name1, t3.name2, t3.name3 , ... from t1 join ... t2 ... join t3 ... where ( t2.name2 + t2.name3 ) like '%test%' т.е. не отрабатывается полиморфное поведение (при этом по отдельности в выборке по каждому классу отрабатывается и sql формируется правильно) Кто-нибудь знает элегантное решение этой проблемы? Может быть я где-то-что-то не правильно указал ? (кстати очень смущает необходимость дублировать логику в маппинг-классах) PS. Гугл подсказал следующие решения: 1. Хранить вычисляемое значение в отдельном private поле и соответственно писать его в базу в родительскую таблицу 2. Выбирать все, потом обработать linq to objects 3. Перестраивать expression tree разнообразными способами. PPS. Может это просто глюк NHibernate.Linq, а обычный NHibernate справляется с такой ситуацией? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 02:04 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Abbey RoadМожет это просто глюк NHibernate.Linq, а обычный NHibernate справляется с такой ситуацией? Я думаю да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 13:15 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
А вообще кто-нибудь такую схему реализовывал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 13:31 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Abbey RoadА вообще кто-нибудь такую схему реализовывал? Что мне не нравится в Вашей схеме, это то, что Вы закладываете под свои Entity единый интерфейс IFoo, который требует реализовать в наследуемых классах 2 члена. Это не всегда прокатит. Для решений с 10-ю табличками, да - эта универсализация сработает. Но на реальных проектах далеко не все Entity должны плясать по таким правилам. Гораздо лучше пометить свои Entity каким-нить базовым классом (для начала пустым) или пустым интерфейсом (для дальнейших обобщений). Во-вторых, как-то тестил я линк ту хибер. Слишком сыроват и малофункционален. Покрывает 10% возможностей классических хибер-запросов. В-третьих, как-то выкладывал вот тут вариант репозитория под хиб, гляньте, может понравится, почитайте топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 13:51 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
авторвот тут вариант Спасибо, ознакомлюсь. Задача стоит в объединении слегка разнородных классов (они уже существуют и могут только дорабатываться) для определенной задачи. Поэтому вводится интерфейс IFoo с требованиями от задачи, для него создается отдельная таблица. А классы дорабатываются с целью реализации интерфейса. В остальном проекте, средств NH.Linq вполне хватает, поэтому и хочется реализовать всё единообразно. Ладно, сегодня посмотрю как nh.linq строит expression tree для таких запросов. И попробую заодно реализовать это на чистом nhibernate. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 14:23 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Abbey RoadПоэтому вводится интерфейс IFoo с требованиями от задачи Вы просто заранее ставите себе палки в колёса :) Abbey RoadИ попробую заодно реализовать это на чистом nhibernate. Спасибо. Ок, отпиш и тесь о результатах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2010, 14:26 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Попробовал на чистом NHibernate без fluent'a, и linq. Итог: ошибка самого NHibernate или я просто не умею правильно настроить Он условие where неправильно формирует, приписывая фильтр не к тому классу-таблице. Запрос: IQuery cq = sx.CreateQuery("from IClient c where c.Caption = :name"); Результат: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Классы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Маппинги Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Буду разбираться дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2010, 20:54 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
Abbey Road Код: plaintext 1. Какой-то глупый запрос, Вам не кажется? Сами подумайте, Surname + Firstname || CompanyName : выглядит по-меньшей мере стратнно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2010, 10:41 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
МСУ Какой-то глупый запрос, Вам не кажется? Сами подумайте, Surname + Firstname || CompanyName : выглядит по-меньшей мере стратнно. Почему бы и нет. Есть клиент физ лицо и юрлицо, по названию клиента хочется произвести поиск. Как решение - создать вьюшку и замапить отдельный класс на нее. В чем преимущество - во вьюшке будет колонка Caption, по которой можно создать индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2010, 10:58 |
|
||
|
Вопрос по вычисляемым свойствам, наследованию и NHibernate.Linq
|
|||
|---|---|---|---|
|
#18+
МСУКакой-то глупый запрос, Вам не кажется? Сами подумайте, Surname + Firstname || CompanyName : выглядит по-меньшей мере стратнно. Немного не понял. Развернете свою мысль? Я веду речь о вычисляемых полях, которые рассчитывают свое значение на основании свойств класса. И, в данный момент, не важно что именно они рассчитывают. Мне нужна выборка по этому полученному значению. А будут это IFoo, IClient, или еще какие хитрые классы реализующие разные стратегии расчета процентных ставок - в тестовом примере это не принципиально. Dmitdd, вариант с view тоже приемлем, но в этом случае нужно учитывать, что нарушается инкапсуляция. В итоге, выбирая наиболее оптимальный для себя вариант и учитывая, что: я не хочу нарушать инкапсуляцию (выносить логику в БД, маппинг классы...) нужен именно быстрый поиск средствами БД (where column = value), используя NHibernate (session.Linq().Where(x=>x.Column == value) решил рассчитывать это самое значение в приватную переменную при изменении зависимых свойств класса и мапить ее на родительскую таблицу. Лишнее место на диске в данной задаче не сильно беспокоит, целостность связанных данных обеспечат транзакции. Не очень нравится это решение, поэтому буду рад комментариям и предложениям. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2010, 23:37 |
|
||
|
|

start [/forum/topic.php?fid=17&gotonew=1&tid=1351509]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
9ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 391ms |

| 0 / 0 |
