My understanding is that Fluent NHibernate doesn't generate the entities. It's just a code equivalent to the hbm file. I think someone else posted the eclipse link ability to generate dynamic classes.
On Tue, May 18, 2010 at 10:17 AM, Kevin Sutter <[email protected]> wrote: > Hi Jean-Baptiste, > I'm with you on this aspect. Producing the .java files, building them, and > then using them in a JVM seems to be a more logical means of accomplishing > this task. > > But, since the poster was asking about the dynamic class approach like the > Fluent Hibernate API, I thought it would still be an interesting exercise > for someone. Just not high on my priority list... :-) > > Kevin > > On Sat, May 15, 2010 at 8:38 AM, Jean-Baptiste BRIAUD -- Novlog < > [email protected]> wrote: > > > How do you generate classes dynamically (at runtime) in Java ??? > > Did you meant modifying the mapping at runtime for existing classes or > did > > you meant producing new classes at runtime and using it just after that > and > > still in the same JVM ? > > > > We are using OpenJPA 2.0 and are generating classes, but this is to > > understand like generation time, before compile time before runtime. > > So, we start producing .java text files that includes JPA annotation, > then > > compiling them, then using them by starting a new JVM. > > To do so, we do not need any JPA dynamic modification not any kind of JPA > > introspection. > > JPA introspection was not needed because the only modification I needed > > coming from Hibernate was a way to change dynamically the eager/fetch > > settings but that wonderful fetchplan feature did the job ! > > > > On 12 mai 2010, at 17:06, Kevin Sutter wrote: > > > > > Hi Matthew, > > > I can agree with the idea of dynamically generating classes at runtime > > and > > > be able to persist them and use them in queries. But, the dynamic > > > generation of mappings makes me go tilt. :-) > > > > > > Kevin > > > > > > On Wed, May 12, 2010 at 9:56 AM, Matthew Adams < > [email protected] > > >wrote: > > > > > >> I don't think the intent is to be able to dynamically change mappings, > > >> although I suppose that's certainly possible. The primary use case > > >> for the metadata API is to be able to generate classes at runtime and > > >> be able to persist them. I didn't follow the metadata API > > >> justification email thread too closely, so there may be other reasons > > >> to have it. > > >> > > >> -matthew > > >> > > >> On Wed, May 12, 2010 at 6:35 AM, Kevin Sutter <[email protected]> > > wrote: > > >>> Hi Christopher, > > >>> Hmmm... Interesting idea, but is this dynamic mapping really > > practical? > > >> It > > >>> sounds like you are looking for the means to dynamically create or > > change > > >>> the mappings defined by your Entity and your database Schema. The > > >> attribute > > >>> types in your Entity definitions will need to match (or at least > easily > > >>> convert to) the types in your database Schema. Since most customer > > >> database > > >>> schemas are fairly static, I don't quite see the need for dynamic > > >> mappings. > > >>> > > >>> Maybe I need another cup of coffee this morning, but I'd still be > > >> interested > > >>> in hearing a specific, real-world use case where the mappings between > > >> your > > >>> Entity and Schema need to be dynamic. > > >>> > > >>> Thanks, > > >>> Kevin > > >>> > > >>> On Tue, May 11, 2010 at 11:33 AM, Christopher Gardner < > > >>> [email protected]> wrote: > > >>> > > >>>> Kevin, > > >>>> > > >>>> The only use case I can think of is the obvious one: a mapping > system > > >>>> more expressive and typesafe than xml, while allowing for > refactoring > > >> and > > >>>> clutter-free entity code. However--and this is just coming off the > > top > > >> of > > >>>> my head as I'm writing--I wonder if there might be needs to compute > > >>>> mappings > > >>>> based on dynamic criteria rather than be bound to compiled > annotations > > >> or > > >>>> static xml (of course, I can't think of what those needs are at the > > >>>> moment). > > >>>> > > >>>> On Tue, May 11, 2010 at 12:21 PM, Kevin Sutter <[email protected]> > > >> wrote: > > >>>> > > >>>>> Hi Christopher, > > >>>>> Now I see what you meant by a "fluent API"... To be honest, my > > >> viewpoint > > >>>>> of > > >>>>> this API was to allow for an alternate means of configuring > > Hibernate, > > >>>>> other > > >>>>> than just using XML. Classic Hibernate only supported > configuration > > >>>>> through > > >>>>> XML, so this fluentHibernate allowed for a programming-based > > mechanism > > >>>> for > > >>>>> configuration. On the surface, it seems like this would be more > > >>>> difficult > > >>>>> to use than just using annotations. > > >>>>> > > >>>>> Can you provide any use cases in the JPA sense that would describe > > how > > >>>> this > > >>>>> type of configuration API would be helpful? > > >>>>> > > >>>>> On a similar vein, we are considering an API to help with > > >> configuration > > >>>> of > > >>>>> the persistence unit. Since the persistence unit is defined by the > > >>>>> persistence.xml only, allowing some alternate means via an API > would > > >> be > > >>>>> welcome. > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> On Tue, May 11, 2010 at 10:27 AM, Christopher Gardner < > > >>>>> [email protected]> wrote: > > >>>>> > > >>>>>> Thanks. I'm in the former camp, i.e., a legacy database. I'm > aware > > >> of > > >>>>> the > > >>>>>> xml alternative. Though I'm no DotNet developer, I read about an > > >>>> Fluent > > >>>>>> NHibernate, which allows you to create a object to store mapping > in > > >>>> code. > > >>>>>> > > >>>>>> http://wiki.fluentnhibernate.org/Getting_started > > >>>>>> > > >>>>>> <http://wiki.fluentnhibernate.org/Getting_started>Maybe such an > API > > >>>>> isn't > > >>>>>> appropriate for a spec, but it would be an interesting alternative > > >> to > > >>>>> both > > >>>>>> annotations and xml for JPA. > > >>>>>> > > >>>>>> On Tue, May 11, 2010 at 11:21 AM, Kevin Sutter < > [email protected]> > > >>>>> wrote: > > >>>>>> > > >>>>>>> Hi Christopher, > > >>>>>>> You're right, annotations can be verbose. But, they don't have > to > > >>>> be. > > >>>>>> It > > >>>>>>> all depends on whether your application can live with the default > > >>>>>>> processing > > >>>>>>> defined by the spec. We tried to pick the most common default > > >> values > > >>>>> for > > >>>>>>> the various annotation elements. If your application can live > > >> with > > >>>> the > > >>>>>>> default processing, then all that is really necessary is the > > >> @Entity > > >>>>> and > > >>>>>>> @Id > > >>>>>>> annotations. But, most legacy applications and schemas can not > > >> live > > >>>>> with > > >>>>>>> the default settings, thus the annotations can become verbose. > > >>>>>> Flexibility > > >>>>>>> can be a killer... But, then we'd be crucified if we didn't > allow > > >>>> for > > >>>>>> the > > >>>>>>> flexibility... :-) > > >>>>>>> > > >>>>>>> The annotations can also be overridden via orm.xml declarations. > > >>>> This > > >>>>>>> would > > >>>>>>> keep your base code more readable, while putting the detailed > gorp > > >>>> into > > >>>>>> the > > >>>>>>> xml file(s). Maybe this would be more suitable for your > > >> environment. > > >>>>>>> > > >>>>>>> Not sure what you mean by "fluent API". Any specific examples to > > >>>> help > > >>>>>> with > > >>>>>>> this discussion? > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Kevin > > >>>>>>> > > >>>>>>> On Tue, May 11, 2010 at 10:10 AM, Christopher Gardner < > > >>>>>>> [email protected]> wrote: > > >>>>>>> > > >>>>>>>> Vis-a-vis all JPA specs, streamlining annotations would be nice. > > >>>> The > > >>>>>>>> annotations can be verbose. Maybe a fluent API would be in > > >> order. > > >>>>>>>> > > >>>>>>>> On Tue, May 11, 2010 at 10:46 AM, Kevin Sutter < > > >> [email protected] > > >>>>> > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>>> Hi Chris, > > >>>>>>>>> Sorry to hear that you are frustrated with JPA 2.0. Can you > > >>>>>> elaborate? > > >>>>>>>>> The > > >>>>>>>>> JPA Expert Group is currently soliciting feedback for the next > > >>>>>> revision > > >>>>>>>> of > > >>>>>>>>> the JPA spec (2.x or 3.0). Here's the e-mail address for this > > >>>>>>>>> correspondence [1]. But, if there are distinct improvements > > >> that > > >>>>> are > > >>>>>>> you > > >>>>>>>>> looking for, maybe they could be entertained by the OpenJPA > > >>>>> community > > >>>>>>>>> first. Bugs and/or Features can be entered into our JIRA > > >> system > > >>>>> [2] > > >>>>>>> for > > >>>>>>>>> future consideration. Of course, community involvement can > > >> help > > >>>>>> speed > > >>>>>>> up > > >>>>>>>>> this process. > > >>>>>>>>> > > >>>>>>>>> Thanks for the input, > > >>>>>>>>> Kevin > > >>>>>>>>> > > >>>>>>>>> [1] [email protected] > > >>>>>>>>> [2] https://issues.apache.org/jira/browse/OPENJPA > > >>>>>>>>> > > >>>>>>>>> On Tue, May 11, 2010 at 9:12 AM, C N Davies <[email protected] > > >>> > > >>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> I'm so frustrated by JPA 2.0 but can't seem to find an JSR > > >> for > > >>>>> JPA > > >>>>>> 3 > > >>>>>>> or > > >>>>>>>>>> anything. Can anyone point me it? > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Thanks J > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Chris > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > >> > > >> > > >> -- > > >> mailto:[email protected] > > >> skype:matthewadams12 > > >> yahoo:matthewadams > > >> aol:matthewadams12 > > >> google-talk:[email protected]<google-talk%[email protected]> > <google-talk%[email protected]<google-talk%[email protected]> > > > > <google-talk%[email protected]<google-talk%[email protected]> > <google-talk%[email protected]<google-talk%[email protected]> > > > > > > > >> msn:[email protected] <msn%[email protected]> < > msn%[email protected] <msn%[email protected]>> < > > msn%[email protected] <msn%[email protected]> < > msn%[email protected] <msn%[email protected]>>> > > >> http://matthewadams.me > > >> http://www.linkedin.com/in/matthewadams > > >> > > > > >
