On May 28, 2006, at 10:50 PM, Max Rydahl Andersen wrote:
> And I guess you really want it disjunct from the mapping and not
> "just" where the assocation is already defined ?
>
>
> ...
>
>...
>
>
>
>
> ...
>
>
>
>
> Where the name could actually be comma seperat
and if that is what it takes, then let that be it ;)
/max
Exactly.
-Original Message-
From: Max Andersen
And I guess you really want it disjunct from the mapping and not
"just"
where the assocation is already defined ?
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hib
Exactly.
-Original Message-
From: Max Andersen
> And I guess you really want it disjunct from the mapping and not
"just"
> where the assocation is already defined ?
---
All the advantages of Linux Managed Hosting--Without the Cost a
It occurred to me today that you could avoid my objection just by
defining the fetch profile in its own section of the XML, instead of in
the association mappings. eg.
And I guess you really want it disjunct from the mapping and not "just"
where the assocation is already def
not looked at Java6 to see if validation of annotations
will help in this area.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Emmanuel Bernard
Sent: Monday, 13 March 2006 7:32 PM
Cc: Hibernate development
Subject: Re: [Fwd: RE: [Hibernate] @Fetch]
Hi,
I
Hi,
I don't fully understand you.
My plan was to add at least org.hibernate.annotations.Lazy and
org.hibernate.annotations.Fetch
They will keep the standard/extension separation clean.
Emmanuel Bernard wrote:
Original Message
Subject: RE: [Hibernate] @Fetch
Original Message
Subject:RE: [Hibernate] @Fetch
Date: Mon, 13 Mar 2006 15:12:44 +1000
From: dchannon <[EMAIL PROTECTED]>
To: 'Emmanuel Bernard' <[EMAIL PROTECTED]>
I feel its best not to confuse what is within the standard and what i
On Mar 13, 2006, at 8:39 AM, Max Rydahl Andersen wrote:
or at least have very good error messages thrown from
the annotation builder.
That should be OK, we never know when other @Fetch options might
become available for collections, etc.
--
hmm ... without any other means of "annotation validation" having
2 seperate annotations sounds like the only way out.
Otherwise you get very dependent on having Hibernate/EJB3 aware
annotations IDE's; or at least have very good error messages thrown from
the annotation builder.
/max
Actually
Actually @Lazy has the same issue
TRUE, FALSE, PROXY, NO-PROXY, EXTRA
@Fetch
SELECT, JOIN, SUBSELECT
Emmanuel Bernard wrote:
I'll add a @Fetch annotation
Some FetchType are available on collections only, some on single
association only.
Do you think I should have 2 different @Fetch annotations
Emmanuel Bernard wrote:
(1) make lazy default to true on both and
mapping elements; if a class cannot be proxied, laziness
is transparently disabled; make it clear that we intend
laziness to be used 99% of the time
Most controversial part but I'm +1 from a pragmatic perspective.
Howeve
* The default should be fetch="select" for collections, what
should the default be for to-one associations? I suppose
that purely for backward compatibility purposes we need
fetch="auto|join|select", where auto is the default, and
chooses "select" for a lazy-enabled class.
Keep the "auto" and t
If you require immediate answers, you need commercial support:
http://hibernate.org/SupportTraining/CommercialSupportAndTrainingForHibernate
Michael Mehrle wrote:
I did - and nobody is replying! Can someone just answer my question?
---
This SF.N
I did - and nobody is replying! Can someone just answer my question?
- Original Message -
From: "Emmanuel Bernard" <[EMAIL PROTECTED]>
To: "Gavin King" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, September 12, 2004 11:44 PM
Subject:
Gavin King wrote:
In my private chats with people, it seems we all agree that
currently, Hibernate2 association fetch strategy configuration
is confusing and has nonsensible defaults. I've spent quite a
lot of time thinking about how we could clean this up without
breaking 2.x mapping documents to
Hi!
(1) make lazy default to true on both and
mapping elements; if a class cannot be proxied, laziness
is transparently disabled; make it clear that we intend
laziness to be used 99% of the time
+1
Hm - i can't remember, does lazy=true on a non-proxyable class fail
today ? (with
a error
16 matches
Mail list logo