Code style and whitespaces
by Sanne Grinovero
Looking at the following patch:
}
- catch (IllegalArgumentException e) {
+ catch ( IllegalArgumentException e ) {
would you consider it an improvement in terms of consistency with the
Hibernate style?
It has always been my interpretation that we use whitespaces inside
blocks, like:
if ( condition)
//rather than
if (condition)
but we don't for constructor invocations:
new Wrapper(type, param);
//rather than
new Wrapper( type, param );
and we also do not (usually) for catch.
I know that might sound like inconsistent, but the point is
readability: I've got used to it and I could swear that the *different
treating* helps with eyeball code scanning.. but I realize that could
be a very personal opinion.
So since we're encoding this rule now in checkstyle, which one shall
it be for the catch statements?
My guts vote goes to
}
catch (IllegalArgumentException e) {
...
but I'd prefer to follow the convention from ORM, if you guys have a
clear rule :-)
Cheers,
Sanne
10 years, 9 months
Re: [hibernate-dev] hibernate-delta
by Steve Ebersole
That's not true. Neither liquibase nor flyway use a connection to the
database.
On Jun 28, 2013 11:22 AM, "Gregor Zeitlinger" <gr.zeitlinger(a)txtr.com>
wrote:
> The tool you mention works against a database connection which is not what
> I want.
>
> Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
>
> >Tools do exist that do this already. Liquibase and Flyway are 2 I know
> >of. Liquibase even has some support for generating its "change logs"
> >from Hibernate mappings[1].
> >
> >[1] http://www.liquibase.org/documentation/hibernate.html
> >
> >
> >On Mon 24 Jun 2013 07:20:15 AM CDT, Gregor Zeitlinger wrote:
> >> The main difference is that hibernate-delta does NOT run against a live
> >> database.
> >> I do load the previous version of a mapping from a custom XML file.
> >>
> >> This enables some scenarios that are not possible with the hibernate
> >> build in schemaupdate, such as
> >>
> >> 1. add a non-null column
> >> 2. change the datatype of a column
> >> 3. rename a column
> >>
> >>
> >> So the workflow is as follows:
> >>
> >> 1. Create an entity Customer
> >> 2. Run UpdateSqlGenerator (which updates the schema.xml file)
> >> 3. Copy the output to a liquibase or Flyway
> >> 4. commit and push schema.xml
> >>
> >> Note that you do not need any database connection for the entire
> workflow.
> >>
> >> I do like to test it on a scratch dump from the live database when I add
> >> a non-null column and fill it with a qeury for example.
> >> In addition, we have an automated test that executes changesets and
> >> compares the final schema with expected one from the annotations - using
> >> hibernate-delta - which in return uses liquibase to read the schema of
> >> the updated database.
> >>
> >> Gregor
> >>
> >>
> >> Am 24.06.2013 11:24, schrieb Max Rydahl Andersen:
> >>> Looks interesting - what is the big difference between this and
> >>> what the built in schemaupdate does ?
> >>>
> >>> If you don't look at previous versions of the mapping I would not
> >>> expect you to do much better (but if you do that would be the natural
> >>> place to contribute it to)
> >>>
> >>> Do you got an example on how to use this ?
> >>>
> >>> /max
> >>>
> >>> On Thu, Jun 20, 2013 at 11:59:51AM +0200, Gregor Zeitlinger wrote:
> >>>> Hi,
> >>>>
> >>>> I've created https://github.com/txtr/hibernate-delta because I
> couldn't
> >>>> find a solution that would generate SQL update statements based on the
> >>>> fields that I added to my @Entity.
> >>>> The trick is that it stores the schema in an XML file that is commited
> >>>> to git. That way, you only get the differences you introduced.
> >>>> It can also find the differences between your XML schema and the
> actual
> >>>> database (using liquibase).
> >>>>
> >>>> Now the questions
> >>>>
> >>>> 1. Is this something that already exists?
> >>>> 2. Is somebody interested in growing this from the current setup
> >>>> (tested with Oracle only)?
> >>>> 3. Would this maybe even a candidate to include in hibernate tools?
> >>>>
> >>>> --
> >>>> Gregor Zeitlinger
> >>>> gregor.zeitlinger(a)txtr.com
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
>
10 years, 9 months
[OGM] Package structure in OGM modules
by Gunnar Morling
Hi,
I'm wondering about the package structure in the provider-specific OGM
modules (hibernate-ogm-mongodb etc.). Why is it e.g.:
org.hibernate.ogm.{datastore|dialect|type|...}.mongodb
instead of
org.hibernate.ogm.mongodb.{datastore|dialect|type|...}
?
Intuitively I'd have expected the latter, as I'd consider the provider as
the more global concept and the different sub-structures of a given
provider as a more specific (sub)-concept.
It surely works both ways, I'm just wondering what the rationale was to go
for the current approach.
Thanks,
--Gunnar
10 years, 9 months
