A
Arne Vajhøj
Given that eager and lazy loading has very specific meaning
in ORM context and this is not quite that, then I think the
term "execute immediately" is a better term.
Arne
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Given that eager and lazy loading has very specific meaning
in ORM context and this is not quite that, then I think the
term "execute immediately" is a better term.
Arne
R
RayLopez99
A collection has to be created without new if there are data - it
is not so surprisingly to me that it does the same with no data.
Yes, perhaps, but it was surprising to me.
RL
A
Arne Vajhøj
It didn't make sense to me either when I worked a project using
nHibernate. You can't use List<T>.
Not true.
In traditional NHibernate:
nHibernate uses its own
implementation of Linq on the .NET platform and it returns IList.
Not true.
In NHibernate LINQ a .ToList() returns an IList<T> (actually
a List<T> that implements IList<T>, but ...).
And since the method is defined in MS code, then I can't
really see how NHibernate could let it behave differently.
Arne
R
RayLopez99
"entity data model" is EF.
"LINQ to SQL classes" is guess what.
I don't know. Haven't a guess. What?
Unusual definition.
But there is.
Using the built in stuff always has some advantages, because
you do not need to integrate things yourself.
And if you are spending 50 hours creating the solution, then
spending 10 hours getting the environment working is huge
overhead.
But if you are working on a 50000 hours projects, then those
10 hours of integration does not matter.
But why waste time? 10 hours is 10 hours. Perhaps nHibernate is
better for "team" projects such as what you describe, taking 50k hours
of programming time--I don't know, I work for myself and code mainly
as a hobby (though I have been getting some commercial projects
lately).
RL
R
RayLopez99
If you don't have an existing database, then the purpose
of the database is to persist your classes. So you define
you classes as they fit the app best. And then the tables
are generated that fits best with the object and the given
ORM framework. That is a lot easier, but not always possible.
And to you your analogy: it makes more sense to define the
donkey cart after the Ferrari than the Ferrari after the donkey cart.
Yes good analogy. I'll have to look into EF and see what the latest
incantation is. Does it come 'built into' Visual Studio 2010, or is
it a special download?
BTW I saw an interesting but speculative article on why Hungary
produces so many math geniuses--the nature of the Hungarian language
is so difficult--apparently it is a form of Reverse Polish Notation (I
guess like Japanese and other Asian languages) and has three different
formal tenses, not to mention certain other grammatical quirks that I
could not even understand in English, that it forces people to think
carefully before they speak--and the theory is this tends to cultivate
one's math skills more. Interesting. This was in The Economist year
end issue that also featured Hungary's famous "mini-cars" from after
WWII (motorcycle engines in a small car, some only 1.5 m high, that
seated only two people--in response to the USSR insistence that
Hungary not build full sized cars).
RL
A
Arne Vajhøj
But why waste time? 10 hours is 10 hours.
It may not be a waste of time.
NHibernate comes with lots of features for some of the
more interesting ORM stuff: lazy loading, caching,
inheritance mapping etc..
Arne
A
Arne Vajhøj
Yes good analogy. I'll have to look into EF and see what the latest
incantation is. Does it come 'built into' Visual Studio 2010, or is
it a special download?
EF came with .NET 3.5 SP1 (probably VS 2008 SP1 but I am not sure).
..NET 4.0 (and VS 2010) came with big improvements for EF.
Arne
A
Arne Vajhøj
BTW I saw an interesting but speculative article on why Hungary
produces so many math geniuses--the nature of the Hungarian language
is so difficult--apparently it is a form of Reverse Polish Notation (I
guess like Japanese and other Asian languages) and has three different
formal tenses, not to mention certain other grammatical quirks that I
could not even understand in English, that it forces people to think
carefully before they speak--and the theory is this tends to cultivate
one's math skills more. Interesting. This was in The Economist year
end issue that also featured Hungary's famous "mini-cars" from after
WWII (motorcycle engines in a small car, some only 1.5 m high, that
seated only two people--in response to the USSR insistence that
Hungary not build full sized cars).
The relevance for the thread is not obvious to me.
Arne
A
Arne Vajhøj
[...]It didn't make sense to me either when I worked a project using
nHibernate. You can't use List<T>.
Not true.
In traditional NHibernate:
..ToList<X>() returns an IList<X>
..ToList() returns an IList
Is that correct? If so, then maybe that's what the person posting as
"Big Steel" is talking about. The .NET Framework implementation of
Enumerable.ToList<T>() returns a List<T>, not IList<T>.
If NHibernate has provided its own extension methods to be used in lieu
of System.Linq.Enumerable and those methods return IList<T> and IList,
then of course you cannot directly assign the return value to a variable
declared as List<T>.
Traditional NHibernate is not LINQ.
Those methods are simply methods in their IQuery interface (if I
remember correct).
The above two statements seem to contradict each other. If NHibernate
LINQ returns IList<T> from ToList<T>(), then it can't be defined in
Microsoft code, because Microsoft's code returns a List<T>, not an
IList<T>.
Traditional NHibernate != NHibernate LINQ
I admit, not being a user of NHibernate myself, I'm at a disadvantage in
trying to explain the comments from the person posting as "Big Steel".
But if NHibernate is actually providing its own LINQ methods
implementation and it's failed to adhere to the API contract that
Microsoft has already published, I could see how in some sense of the
word "can't", you "can't" use List<T> with NHibernate (i.e. in that
narrow scenario where you're trying to assign the return value from
ToList<T>() to a variable).
As far as I can tell NHibernate LINQ works exactly like MS
intended.
IList<T1> res4 = (from t1 in s.Linq<T1>() select t1).ToList();
works.
Traditional NHibernate is not exposing a MS API, so no surprise
that it is a bit different.
That looks like:
IList<T1> res1 = s.CreateQuery("FROM T1 AS t1").List<T1>();
IList res2 = s.CreateQuery("FROM T1 AS t1").List();
Arne
R
RayLopez99
The relevance for the thread is not obvious to me.
Arne
Yeah, another study found that people like you, good in math, tend to
have very poor social skills and tend to be dyslexic. Explains the
low birth rate of Hungary and why they are heading for the dustbin of
history.
RL
A
Arne Vajhøj
[...]If NHibernate has provided its own extension methods to be used in lieu
of System.Linq.Enumerable and those methods return IList<T> and IList,
then of course you cannot directly assign the return value to a variable
declared as List<T>.
Traditional NHibernate is not LINQ.
Since the person posting as "Big Steel" has been specifically talking
about LINQ (e.g. "…nHibernate uses its own implementation of Linq…"), it
seems safe to assume that we are discussing "NHibernate LINQ", and not
"Traditional NHibernate". When I write "NHibernate" alone, you should
take that to refer to the former.
Well - I specifically stated "traditional NHibernate".
I don't think you should assume that when I explicit say X that I
really means Y.
[...]
As far as I can tell NHibernate LINQ works exactly like MS
intended.
IList<T1> res4 = (from t1 in s.Linq<T1>() select t1).ToList();
works.
But this would not:
List<T1> res4 = (from t1 in s.Linq<T1>() select t1).ToList();
This works as well.
But I can't see any reason to write it that way.
…if NHibernate is providing a different "ToList" extension method, that
returns an IList<T> instead of List<T> as the .NET one does.
In other words, "NHibernate LINQ" would _not_ work "exactly like MS
intended", assuming your previous statement about it returning IList<T>
instead of List<T> is correct.
Again: you will benefit from reading what I write. A little
back I wrote:
#In NHibernate LINQ a .ToList() returns an IList<T> (actually
#a List<T> that implements IList<T>, but ...).
It is beyond me how you can make that fit with "your previous
statement about it returning IList<T> instead of List<T> is correct".
Arne
A
Arne Vajhøj
Yeah, another study found that people like you, good in math, tend to
have very poor social skills and tend to be dyslexic. Explains the
low birth rate of Hungary and why they are heading for the dustbin of
history.
????
Arne
A
Arne Vajhøj
[...]
If NHibernate has provided its own extension methods to be used in lieu
of System.Linq.Enumerable and those methods return IList<T> and IList,
then of course you cannot directly assign the return value to a
variable
declared as List<T>.
Traditional NHibernate is not LINQ.
Since the person posting as "Big Steel" has been specifically talking
about LINQ (e.g. "…nHibernate uses its own implementation of Linq…"), it
seems safe to assume that we are discussing "NHibernate LINQ", and not
"Traditional NHibernate". When I write "NHibernate" alone, you should
take that to refer to the former.
Well - I specifically stated "traditional NHibernate".
I don't think you should assume that when I explicit say X that I
really means Y.
[...]
As far as I can tell NHibernate LINQ works exactly like MS
intended.
IList<T1> res4 = (from t1 in s.Linq<T1>() select t1).ToList();
works.
But this would not:
List<T1> res4 = (from t1 in s.Linq<T1>() select t1).ToList();
This works as well.
But I can't see any reason to write it that way.
…if NHibernate is providing a different "ToList" extension method, that
returns an IList<T> instead of List<T> as the .NET one does.
In other words, "NHibernate LINQ" would _not_ work "exactly like MS
intended", assuming your previous statement about it returning IList<T>
instead of List<T> is correct.
Again: you will benefit from reading what I write. A little
back I wrote:
#In NHibernate LINQ a .ToList() returns an IList<T> (actually
#a List<T> that implements IList<T>, but ...).
It is beyond me how you can make that fit with "your previous
statement about it returning IList<T> instead of List<T> is correct".
And to try and be completely clear: as far as I can tell then
NHibernate LINQ is totally LINQ standard, using the MS LINQ API's
as is. Not fiddling with IEnumerable<> extension methods.
I don't even know if it is possible to fiddle with those.
It does provide its own LINQ implementation. It has to. All
LINQ's has to provide something actually implementing
the underlying functionality.
Arne
R
RayLopez99
The relevance for the thread is not obvious to me.
Arne
My point EXACTLY! Your brain Arne is hardwired differently from the
rest of us--because of speaking and thinking in Hungarian language.
RL
R
RayLopez99
????
Arne
Ooops, sorry, I thought this post was deleted...didn't know it made it
through.
I have really shitty internet connections here in Greece--don't know
about Hungary, but this country sucks for internet.
RL
A
Arne Vajhøj
My point EXACTLY! Your brain Arne is hardwired differently from the
rest of us--because of speaking and thinking in Hungarian language.
I somewhat doubt that Hungarians are that different from other people.
I know with absolutely certainty that I don't know a single
word in Hungarian.
Arne
A
Arne Vajhøj
No that's not true
Yes. It is.
LINQ ToList() returns a List<>.
Check the docs yourself.
and nHibernate that I was using with its Linq
implementation only returned IList.
It does not today.
And I find it a bit difficult to see how it could, because IEnumerable<>
ToList is in MS code not NHibernate code.
Arne
A
Arne Vajhøj
Every last bit of it can be done with EF.
Possible. I am not that familiar with the advanced EF stuff.
When did they add built in second level cache to EF. They
used to only provide a SPI.
Arne
A
Arne Vajhøj
You do know what a Linq provider is, right? It can have its own
implementation of Linq.
http://www.caffeinatedcoder.com/linq-to-nhibernate/
A Linq provider in this link can be a provider that has a different
implementation of Linq.
http://www.alinq.org/
All usages of LINQ requires a provider. There needs
to be some underlying code.
But IEnumerable<> .ToList() is not in the provider - it is in
System.Core.dll
from Microsoft.
You were not there in that shop using nHibernate and the implementation
of Linq being used in that shop.
No.
But it is possible to post actual code that show it returning
a IList<> (actually a List<> but I prefer the interface).
And no one has so far explained how one replaces Microsoft's
IEnumerable<> .ToList() method.
Arne
A
Arne Vajhøj
EF that I know about even in the SP1 version had object caching.
I know that EF has first level caching. I am specifically asking
for second level caching.
Arne