That's good advice too. In any case, it really depends on the type of
report. I wonder what they do with something that has 20K lines.
Diego
On Tue, Aug 31, 2010 at 15:51, Jeffry Morris <[email protected]> wrote:
> In general no ORM is good tool for reporting scenarios; that is the domain
> of OLAP software and in simpler cases SSRS or crystal reports. For very
> simple reporting ORMs (including NH) will work, but you will quickly run
> into limitations and scalability issues.
>
> On Tue, Aug 31, 2010 at 11:34 AM, Diego Mijelshon
> <[email protected]>wrote:
>
>> If the values are mapped correctly (ie. the datatypes match), I don't see
>> how the number of records could cause invalid values to be retrieved, so
>> it's more likely to be caused by a wrong query that doesn't take things like
>> Identity Map into account.
>> But you should create a Jira issue (http://jira.nhforge.org) if you can
>> create a repro test.
>> A more-or-less-obvious piece of advice is that you should use
>> StatelessSession for that kind of query.
>> In any case, if ADO.NET works well and you are not using almost any
>> feature of NH for that case, you can just leave it out.
>>
>> Diego
>>
>>
>>
>> On Tue, Aug 31, 2010 at 15:20, Eric W. Brown <[email protected]>wrote:
>>
>>> Sorry, That’s kind of what I was hoping to get answered, a better
>>> definition of the line where Nh becomes sub optimal where “reporting” and
>>> “nulk” becomes more than you should do with NH..
>>>
>>>
>>>
>>> In our particular case we are writing a reporting application that
>>> fetches say 20k rows, of say 50-70 columns tio generate rldc report. We get
>>> Random occurrences of some columns coming back with zeros, when the same SQL
>>> run by hand returns the correct values.
>>>
>>>
>>>
>>> The larger the # of rows & columns the more consistently it fails (for
>>> one report about 75% of the time)
>>>
>>>
>>>
>>> We swap from doing those queries via NH to straight ado.net and the
>>> problem goes away. (about 5 lines of code changed).
>>>
>>>
>>>
>>> I was hoping to get a feel for the line where it ceases to be rock solid.
>>> A speed slowdown is one thing, but failing to return data on some columns is
>>> not a show starter.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Eric-
>>>
>>>
>>>
>>> *From:* [email protected] [mailto:[email protected]] *On
>>> Behalf Of *Diego Mijelshon
>>> *Sent:* Tuesday, August 31, 2010 1:04 PM
>>> *To:* [email protected]
>>> *Subject:* Re: [nhusers] Re: MsSqlCeDialect and TOP keyword
>>>
>>>
>>>
>>> Well, those are really broad questions.
>>>
>>> NHibernate works very well for most scenarios that use ADO.NET. It can
>>> be used in different ways and it can be tweaked to get better performance
>>> and flexibility than most ad-hoc implementations.
>>>
>>> That said, you don't have to use it as your only tool. And there's no
>>> problem in mixing it with other approaches for some operations.
>>>
>>> If you want more detail, you should define "DAL", "reporting" and "bulk
>>> operations" more precisely
>>>
>>> Diego
>>>
>>> On Tue, Aug 31, 2010 at 13:52, Eric W. Brown <[email protected]>
>>> wrote:
>>>
>>>
>>>
>>> Hi all I have a few quick questions, I’d like to ask if that’s okay… Just
>>> trying to
>>>
>>> Remove the Grey and Fuzzy from some things I’ve read about NHibernate.
>>>
>>>
>>>
>>> I’ve heard that you shouldn’t use NHibernate for “Reporting and Bulk
>>> Operations”
>>>
>>>
>>>
>>> Why not?
>>>
>>> Where is the line for “bulk operations” ? at what point does it become
>>> too much for NHibernate.
>>>
>>>
>>>
>>> Also I’ve heard that using NHibernate via a DAL, defeats the whole point
>>> of using NHibernate, is this true?
>>>
>>> Why?
>>>
>>>
>>>
>>> Thanks a lot, I’m looking forward to your accumulated wisdom on the
>>> subjects.
>>>
>>>
>>>
>>> Eric-
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "nhusers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]<nhusers%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/nhusers?hl=en.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "nhusers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]<nhusers%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/nhusers?hl=en.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "nhusers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]<nhusers%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/nhusers?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "nhusers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<nhusers%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/nhusers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<nhusers%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
