>
>
>> * Are MetadataSources#addAttributeConverter(),
>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>> meta-data really? Somehow it seems they should rather be located on
>> MetadataBuilder?
>>
>
> From one perspective yes. Not *sources* per-se, but they are things tha
On second thought...
MetadataBuilder is also an interface (unless you are suggesting to change
that for some reason), so not sure how a call like this would work:
MetadataBuilder.defineSources()
On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole wrote:
> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar
On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling
wrote:
> > 1) What do you think of the split in MetadataSources and MetadataBuilder?
> > Does the aplit make sense? Or does it make more sense to combine them
> into
> > one contract?
>
> I think the split makes sense, as I understand that there ar
Hi,
While INSERT sorting is handled by ActionQueue.InsertActionSorter, DELETE
statements are not sorted at all.
A DeleteActionSorter woudl have to rearrange DELETES in the opposite order as
the INSERT sorting, the Children having to be deleted first.
The current work-around is to dissociate all C
> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense? Or does it make more sense to combine them
into
> one contract?
I think the split makes sense, as I understand that there are two different
"phases" of configuration here:
* add multiple sour
On Wed, Mar 25, 2015 at 12:20:27PM -0500, Steve Ebersole wrote:
> I can get behind that.
>
> Anyone else?
+1
--Hardy
pgpsAu_1TGhVe.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/ma
We also identified needs for Status#ROLLING_BACK and Status#COMMITTING, so
consider those in the enum as well.
On Wed, Mar 25, 2015 at 12:19 PM, Steve Ebersole
wrote:
> I thought I had asked this before, but maybe not. Andrea and I are
> working through the transaction/jdbc changes and I really
I can get behind that.
Anyone else?
On Wed, Mar 25, 2015 at 11:28 AM, Gunnar Morling
wrote:
> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods?
>
> I find it sub-optimal as it falls apart if there are several para
I thought I had asked this before, but maybe not. Andrea and I are working
through the transaction/jdbc changes and I really would like to clean up
the org.hibernate.Transaction API. But before I start cutting I wanted to
make sure noone is using the methods I plan on getting rid of...
Here is t
2) What do you think of all the overloaded methods named #with tacking
different argument types, versus distinctly named methods?
I find it sub-optimal as it falls apart if there are several parameters of
the same type (e.g. String or boolean). This leads to some irregularities
in the names, e.g.
We eventually got something working. Was a PITA though.
On Mar 25, 2015 4:18 AM, "Hardy Ferentschik" wrote:
> On Tue, Mar 24, 2015 at 08:40:05AM -0500, Steve Ebersole wrote:
> > AnimalSniffer is causing us a lot of headaches in conjunction with Java
> 8.
>
> Ahh, right. I forgot about this. I so
On Tue, Mar 24, 2015 at 08:40:05AM -0500, Steve Ebersole wrote:
> AnimalSniffer is causing us a lot of headaches in conjunction with Java 8.
Ahh, right. I forgot about this. I somehow thought that was resolved by now.
> Gunnar suggested overriding the ASM version used, but that did not help for
>
12 matches
Mail list logo
