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
-
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
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
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
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
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
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
&
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
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
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
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...
>>
>>
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
...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
> 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
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
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
> > 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
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
* 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
>
>>>
>>> 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
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
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
> 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
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
>> * 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
25 matches
Mail list logo
