11:45 a.m.
Hi everyone,
I am writing to make a proposal to refactor the Configuration class as an
interface and and implementation for the reason below.
It would allow third-party developers as myself to use proxies and
decorators with default configuration.
For example, in groovy.grails they extend the Configuration class. I may
extend DefaultGrailsDomainConfiguration but if there were another developer
he would have to choose which child to extend which makes things trickier.
To be precise I am playing with generateSchemaCreationScript and
generateSchemaUpdateList. I want to do things with default scripts by
simply wrapping around configuration given.
Kind Regards,
Andrey Polyakov
7:35 p.m.
This Configuration class is being deprecated in 5.0, take a look of the new interface :)
org.hibernate.metadata package:
* MetadataSources
* Metadata
* MetadataBuilder
* SessionFactoryBuilder
On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals(a)gmail.com> wrote:
Hi everyone,
I am writing to make a proposal to refactor the Configuration class as an
interface and and implementation for the reason below.
It would allow third-party developers as myself to use proxies and
decorators with default configuration.
For example, in groovy.grails they extend the Configuration class. I may
extend DefaultGrailsDomainConfiguration but if there were another developer
he would have to choose which child to extend which makes things trickier.
To be precise I am playing with generateSchemaCreationScript and
generateSchemaUpdateList. I want to do things with default scripts by
simply wrapping around configuration given.
Kind Regards,
Andrey Polyakov
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:29 a.m.
Thank you for your reply Shaozhuang Liu. I assume the classes you advised
me is not what I need.
Ineed, I need to work after the following method:
http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/cfg/Config...,
org.hibernate.tool.hbm2ddl.DatabaseMetadata)
Moreover, it seems that the class org.hibernate.cfg.Configuration is not
deprecated
On Tue, Dec 24, 2013 at 7:35 AM, Shaozhuang Liu <stliu(a)hibernate.org> wrote:
This Configuration class is being deprecated in 5.0, take a look of
the
new interface :)
org.hibernate.metadata package:
* MetadataSources
* Metadata
* MetadataBuilder
* SessionFactoryBuilder
On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals(a)gmail.com>
wrote:
> Hi everyone,
>
> I am writing to make a proposal to refactor the Configuration class as an
> interface and and implementation for the reason below.
>
> It would allow third-party developers as myself to use proxies and
> decorators with default configuration.
>
> For example, in groovy.grails they extend the Configuration class. I may
> extend DefaultGrailsDomainConfiguration but if there were another
developer
> he would have to choose which child to extend which makes things
trickier.
>
> To be precise I am playing with generateSchemaCreationScript and
> generateSchemaUpdateList. I want to do things with default scripts by
> simply wrapping around configuration given.
>
> Kind Regards,
>
> Andrey Polyakov
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:38 a.m.
Configuration is softly deprecated; the class itself is not marked
@Deprecated (just a single method on it is). The reason for that is
discussed elsewhere, so I won't go back into specifics. Suffice it to
say that it is to make way for an improved means of bootstrapping that
it coming in 5.0. In the interest of "forward compatibility" (apps
upgrading Hibernate version) I will make every effort to allow "normal"
existing usage of Configuration to work unchanged in 5.0 as well
(Configuration would just delegate to the new bootstrap SPI).
Long story short... we most definitely do not want to make major changes
(like this proposal) to Configuration. That being said, *you* can
certainly extend Configuration and supply your override of the
generateSchemaUpdateScript method and have your users use that extended
Configuration.
On 12/24/2013 02:29 AM, Andrey Polyakov wrote:
Thank you for your reply Shaozhuang Liu. I assume the classes you
advised
me is not what I need.
Ineed, I need to work after the following method:
http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/cfg/Config...,
org.hibernate.tool.hbm2ddl.DatabaseMetadata)
Moreover, it seems that the class org.hibernate.cfg.Configuration is not
deprecated
On Tue, Dec 24, 2013 at 7:35 AM, Shaozhuang Liu <stliu(a)hibernate.org> wrote:
> This Configuration class is being deprecated in 5.0, take a look of the
> new interface :)
>
> org.hibernate.metadata package:
>
> * MetadataSources
> * Metadata
> * MetadataBuilder
> * SessionFactoryBuilder
>
> On Dec 24, 2013, at 1:45, Andrey Polyakov <polyakovfromurals(a)gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I am writing to make a proposal to refactor the Configuration class as an
>> interface and and implementation for the reason below.
>>
>> It would allow third-party developers as myself to use proxies and
>> decorators with default configuration.
>>
>> For example, in groovy.grails they extend the Configuration class. I may
>> extend DefaultGrailsDomainConfiguration but if there were another
> developer
>> he would have to choose which child to extend which makes things
> trickier.
>> To be precise I am playing with generateSchemaCreationScript and
>> generateSchemaUpdateList. I want to do things with default scripts by
>> simply wrapping around configuration given.
>>
>> Kind Regards,
>>
>> Andrey Polyakov
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3784
days inactive
3791
days old
3 comments
3 participants
participants (3)
-
Andrey Polyakov -
Shaozhuang Liu -
Steve Ebersole