don't know if this got through but just got yet another "mail delivery
failure" for it...so here it goes again ;)
Gavin King wrote:
* Support for JSR-175 annotations (Emmanuel)
JSR-175 is the new metadata in the core java language right ?
Then is that not something xdoclet will take care of ev
Now that 3.2.0.ga is imminent, here are the things which are currently
underway, or which I would like to start soon:
1) Antlr query translator redesign. The original Antlr-based translator
was a great first cut and showed us the usefulness of Antlr for this
task; in many ways it ways a learning
>> * Support for JSR-175 annotations (Emmanuel)
>
>
> JSR-175 is the new metadata in the core java language right ?
> Then is that not something xdoclet will take care of eventually or
> do you have something else in mind ?
>
Here is the idea. I don't know how and when xdoclet will embrace JSR 175
Hi,
JSR-175 is the new metadata in the core java language right ?
Then is that not something xdoclet will take care of eventually or
do you have something else in mind ?
Here is the idea. I don't know how and when xdoclet will embrace JSR 175
but I can imagin they will stay stucked with (pre)compi
> eg. metadata
> would be a replacement for mapping files - which I thing would be rather
> cool.
>
> Michael
Not replacement, user will have the choice (either .hbm.xml or JSR-175)
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Bu
Michael Gloegl wrote:
Hi,
JSR-175 is the new metadata in the core java language right ?
Then is that not something xdoclet will take care of eventually or
do you have something else in mind ?
Here is the idea. I don't know how and when xdoclet will embrace JSR 175
but I can imagin they will stay
Actually I don't think using JSR-175 metadata in XDoclet will be so
easy, because to use the Metadata-API you need the compiled class
files and compiling the class files is often not possible without
running XDoclet before (not for Hibernate but easily for EJBs for
example). So i really think
>
>>>
>>> Actually I don't think using JSR-175 metadata in XDoclet will be so
>>> easy, because to use the Metadata-API you need the compiled class
>>> files and compiling the class files is often not possible without
>>> running XDoclet before (not for Hibernate but easily for EJBs for
>>> example
* Support for JSR-175 annotations (Emmanuel)
JSR-175 is the new metadata in the core java language right ?
Then is that not something xdoclet will take care of eventually or
do you have something else in mind ?
Correct. JSR175 is a better fit to what we want because
we don't actually need code
It will just be built underneath existing functionality like
delete(query) and orphan delete. It will support all
Hibernate semantics. So this:
session.delete("from Foo foo where foo.name like 'foo'")
will cause two queries:
SELECT ... FROM FOO WHERE NAME LIKE 'foo'
DELETE FROM FOO WHERE NAME
> > It will just be built underneath existing functionality like
> > delete(query) and orphan delete. It will support all
> > Hibernate semantics. So this:
> >
> > session.delete("from Foo foo where foo.name like 'foo'")
> >
> > will cause two queries:
> >
> > SELECT ... FROM FOO WHERE NAME LIKE 'f
Max Rydahl Andersen wrote:
> ok - so instead of deleting one at the time, we batch delete, but still
call all the lifecycle stuff ?
> (but isn't the users just going to ask for a quick batch delete instead
then (to avoid the possible expensive delete ? ;)
I'm sure they will /ask/.
--
Gavin
Ara Abrahamian wrote:
And this will take into account cascade=all|delete too?
My bad, when I wrote "orphan delete", I meant to say "casade delete". It
would not work for orphan delete.
--
Gavin King
JBoss Group
+61 410534454
http://hibernate.org
> 1) Antlr query translator redesign. The original Antlr-based translator
> was a great first cut and showed us the usefulness of Antlr for this
> task; in many ways it ways a learning experience. Now, it is time to
> take those experiences and redesign how the translator works in a few
> areas
Regarding the component related changes mentioned in the previous
email...
As I mentioned a lot of the pre-requisite work has already been
performed on HEAD. I also took the opportunity to refactor the
packaging of the org.hibernate.tuple package. Specifically, most of the
pre-requisite work was
Sent: Monday, July 17, 2006 9:50 AM
To: Steve Ebersole; Hibernate development
Subject: Re: [Hibernate] Roadmap
> 1) Antlr query translator redesign. The original Antlr-based
translator
> was a great first cut and showed us the usefulness of Antlr for this
> task; in many ways it w
since
the sf-level control of bytecode gen would be good (but i don't know
if it is critical-critical?)
>
> -Original Message-
> From: Max Andersen
> Sent: Monday, July 17, 2006 9:50 AM
> To: Steve Ebersole; Hibernate development
> Subject: Re: [Hibernate] Roadmap
&
Regarding the HQL translator related changes mentioned in the previous
email...
Mainly, this is involving a fairly large scale refactoring of the Antlr
grammars and the associated code.
The first aspect was previously discussed on this list, so I won't go
into all the gory details. Basically, th
...but requires changes to public API so probably best suited for 3.3.
> Regarding the component related changes mentioned in the previous
> email...
>
> As I mentioned a lot of the pre-requisite work has already been
> performed on HEAD. I also took the opportunity to refactor the
> packaging of
Type is *NOT* a public API...
-Original Message-
From: Max Andersen
Sent: Monday, July 17, 2006 10:38 AM
To: Steve Ebersole; Hibernate development
Subject: Re: [Hibernate] Roadmap - components
...but requires changes to public API so probably best suited for 3.3.
> Regarding
38 AM
> To: Steve Ebersole; Hibernate development
> Subject: Re: [Hibernate] Roadmap - components
>
> ...but requires changes to public API so probably best suited for 3.3.
>
>> Regarding the component related changes mentioned in the previous
>> email...
>>
>>
the underlying Type system...
-Original Message-
From: Max Andersen
Sent: Monday, July 17, 2006 10:43 AM
To: Steve Ebersole; Hibernate development
Subject: Re: [Hibernate] Roadmap - components
On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole
<[EMAIL PROTECTED]> wrote:
> Typ
insulate the user
> from changes in the underlying Type system...
>
> -Original Message-
> From: Max Andersen
> Sent: Monday, July 17, 2006 10:43 AM
> To: Steve Ebersole; Hibernate development
> Subject: Re: [Hibernate] Roadmap - components
>
> On Mon, 17
17, 2006 10:51 AM
To: Steve Ebersole; Hibernate development
Subject: Re: [Hibernate] Roadmap - components
point taken.
> Well Type and UserType do not necessarily need to be in synch in this
> particular regard. We could conceivably change Type and then later
> (i.e. as part of a major
d we somehow allow both possibilities for the sake of compability ?
And I know Christian will "love" us for changing this so close to the book
release ;)
/max
> -Original Message-
> From: Max Andersen
> Sent: Monday, July 17, 2006 10:51 AM
> To: Steve Ebersole; Hibernate
lso get in here)
Could we somehow allow both possibilities for the sake of compability ?
And I know Christian will "love" us for changing this so close to the
book
release ;)
/max
> -Original Message-
> From: Max Andersen
> Sent: Monday, July 17, 2006 10:51
Another is
> PropertyAccessors. Yet another is ComponentTuplizers.
>
> -Original Message-
> From: Max Andersen
> Sent: Monday, July 24, 2006 2:18 AM
> To: Steve Ebersole; Hibernate development
> Subject: Re: [Hibernate] Roadmap - components
>
>
>> So that
-
From: Max Andersen
Sent: Tuesday, July 25, 2006 12:35 PM
To: Steve Ebersole
Cc: Hibernate development
Subject: Re: [Hibernate] Roadmap - components
Regarding handling users migration of code then I guess (one of) the
worst
parts is where users have query/criteria building code that does not
hav
Hi,
I am jumping in lately but the discussion about a new ANTLR translator
is very interesting to me.
> The first aspect was previously discussed on this list, so I won't go
> into all the gory details. Basically, the current Antlr-based
> translator translates an HQL query in 3 phases where eac
29 matches
Mail list logo
