From stliu at hibernate.org Fri Aug 10 12:42:03 2012
Content-Type: multipart/mixed; boundary="===============6899798006298991517=="
MIME-Version: 1.0
From: Strong Liu <stliu at hibernate.org>
To: hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] SchemaManagementTool / Exportable
Date: Sat, 11 Aug 2012 00:42:04 +0800
Message-ID: <593C0348-8158-437F-96F1-3092B554AE71@hibernate.org>
In-Reply-To: 502536FF.1040105@hibernate.org

--===============6899798006298991517==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

the first one looks simpler and more clear I think

On Aug 11, 2012, at 12:29 AM, Steve Ebersole <steve(a)hibernate.org> wrote:

> What is everyones thoughts on having Exporter contain methods for create,=
 drop and alter scenarios versus getting Exporter per each of those actions?
> =

> interface Exporter<T extends Exportable> {
>   public String[] sqlCreateStrings(T exportable, Dialect dialect);
>   public String[] sqlDropStrings(T exportable, Dialect dialect);
>   public String[] sqlMigrationStrings(T exportable, Dialect dialect);
> }
> =

> +
> =

> Exporter<Table> gerTableExporter() {
>   return ...;
> }
> =

> =

> =

> versus
> =

> interface Exporter<T extends Exportable> {
>   public String[] sqlExportStrings(T exportable, Dialect dialect);
> }
> =

> Exporter<Table> gerTableExporter(Exporter.Action typeOrExport) {
>   return ...;
> }
> =

> I think the first is simpler for our use cases, but I can see how the sec=
onds might be simpler for custom ones.
> =

> On Fri 10 Aug 2012 01:49:48 AM CDT, Gail Badner wrote:
>> +1
>> =

>> ----- Original Message -----
>>> From: "Strong Liu" <stliu(a)hibernate.org>
>>> To: "Steve Ebersole" <steve(a)hibernate.org>
>>> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org>
>>> Sent: Thursday, August 9, 2012 9:15:32 PM
>>> Subject: Re: [hibernate-dev] SchemaManagementTool / Exportable
>>> =

>>> =

>>> +1
>>> =

>>> On Aug 10, 2012, at 12:38 AM, Steve Ebersole <steve(a)hibernate.org>
>>> wrote:
>>> =

>>>> The basics of org.hibernate.service.schema.spi.SchemaManagementTool
>>>> are
>>>> essentially done.  There is a lot of clean up I want to do after
>>>> Configuration is gutted or removed, changing how SchemaExport, etc
>>>> work
>>>> internally.
>>>> =

>>>> But one thing I wanted to discuss was to change up how Exportable
>>>> works.
>>>>  Today, its really not much different than what we used to do.  The
>>>> database objects themselves know how to render themselves into SQL
>>>> CREATE/DROP/ALTER commands.  What I am contemplating is
>>>> externalizing
>>>> this rendering (lets call them ExportableRenderer, thought better
>>>> names
>>>> welcome).  This would serve 2 useful purposes:
>>>> 1) Clean up the Table, Sequence, etc code clutter.
>>>> 2) Allow plugging in alternate renderings for things.  This could
>>>> be
>>>> dialects or users or event custom SchemaManagementTool supplied.
>>>> =

>>>> WDYT?
>>>> =

>>>> --
>>>> steve(a)hibernate.org
>>>> http://hibernate.org
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> =

>>> -------------------------
>>> Best Regards,
>>> =

>>> Strong Liu <stliu at hibernate.org>
>>> http://about.me/stliu/bio
>>> =

>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> =

> =

> --
> steve(a)hibernate.org
> http://hibernate.org

-------------------------
Best Regards,

Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio


--===============6899798006298991517==--