Gavin King wrote:
So, I realised today that most of the stuff I want out of a
StoredProcedurePersister is already available in iBATIS SQL Maps
(http://www.ibatis.com). So why not simply write a standard
iBATISPersister and leverage this existing code, instead of
reinventing wheels?
I'm always
For some reason this mail did not get through my smtp server...so here
it is again ;)
I'm +1 for generics in 2.2, it might help people understand and use
generics better and more
...but it would be nice if you outlined what you think needs changing
and what it will provide ?
/max
Gavin King
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
>> * 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
Hi all,
I'd totally support an iBATISPersister if it helped out the Hibernate
project. Although, I'm also in agreement with Max. I suppose in the
end I don't think Hibernate should depend on iBATIS simply for stored
procedure support. It's too small and simple a feature to force iBATIS
into.
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
Clinton Begin wrote:
Hi all,
I'd totally support an iBATISPersister if it helped out the Hibernate
project. Although, I'm also in agreement with Max. I suppose in the
end I don't think Hibernate should depend on iBATIS simply for stored
procedure support. It's too small and simple a feature
13 matches
Mail list logo
