[OGM] CI and MongoDB tests
by Emmanuel Bernard
>From what I can see and understand the OGM builds (hibernate-ogm-master
specifically) do not test MongoDB. Is that something expected? Can we
envision adding MongoDB testing?
Emmanuel
12 years, 10 months
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
12 years, 10 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
> >>
>
12 years, 10 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
12 years, 10 months
