hello,i am chinese ,so my english is not good ,sorry! i use hibernate orm +
jdts.13 connection sqlserver 2008 , and there are a class of User .
class User
{
private Blob pictureImg;
..
}
when i save user ,i got a problem "
net.sourceforge.jtds.jdbc.JtdsPrep
Hardy,
This one is really a blocker for us as we have to put something into
production really soon with 4.4.2 and we can't do it atm. I take the
liberty to open a JIRA issue so that I can start working on a PR with
a test showing what we do and a fix.
While it looks like it was not an intented fe
On 27 Jan 2014, at 14:46, Guillaume Smet wrote:
> I don't think a test would be useful to understand what we do. Here
> are a few additional information about our business case.
Not sure. I think it always helps to see the whole picture.
> The fact is that we have complex business rules which
On 28 Jan 2014, at 10:52, Guillaume Smet wrote:
> This one is really a blocker for us as we have to put something into
> production really soon with 4.4.2 and we can't do it atm. I take the
> liberty to open a JIRA issue so that I can start working on a PR with
> a test showing what we do and a
We could use either a different annotation or a flag
@ContainedIn(someVerySmartName=SomeVerySmartValue)
On Fri 2014-03-28 11:44, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 10:52, Guillaume Smet wrote:
>
> > This one is really a blocker for us as we have to put something into
> > produ
Nope, but this would local to your system. It works for me and it is
working in CI
On Fri, Mar 28, 2014 at 12:52 AM, Gail Badner wrote:
> After pulling, I am getting a failure executing
> :hibernate-core:runAnnotationProcessors.
>
> I tried building with --debug and it looks like the
> hiberna
On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote:
> We could use either a different annotation or a flag
>
>@ContainedIn(someVerySmartName=SomeVerySmartValue)
I was also wondering whether a whole new annotation would make sense, but
nothing intuitive
came to mind right away. I guess @Con
Have we by now reached a consensus on wether or not to address the package
split?
Anyone against generally against it?
—Hardy
On 27 Jan 2014, at 14:17, Emmanuel Bernard wrote:
> On Thu 2014-03-27 12:40, Hardy Ferentschik wrote:
>>> the tricky part is that today SearchFactoryIntegrator extends
I again have in mind adding some test assertions that a particular logging
(WARN) message gets triggered. We have already one such test in place,
which is one of the places where our usage of byteman comes in.
Given the problems using byteman is causing in CI and the fact that our
reliance on it
On 28 March 2014 11:37, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 12:16, Emmanuel Bernard wrote:
>
>> We could use either a different annotation or a flag
>>
>>@ContainedIn(someVerySmartName=SomeVerySmartValue)
>
> I was also wondering whether a whole new annotation would make sense, bu
I had the same thoughts recently!
My idea would be to have a Logger implementation which logs into an
in-memory buffer, which you can lookup somehow. For my own test needs,
even a static accessor would do. It could be a simple text
representation, or it could store a smarter event-list with some
a
On 27 Jan 2014, at 23:54, Steve Ebersole wrote:
> This is a bit of a potentially insidious one. Not the best way to start
> off a discussion, I know :)
>
> The premise is this... Until now Hibernate has represented attribute roles
> using dots. For an attribute named 'department' on the com.a
On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
> I'd then remove Log4J from our test dependencies to primarily rely on
> assertions only;
Why would you do that? I would expect whatever solution we come up with to
just delegate to the underlying logger.
> or for debugging purposes to have it
> Even better, internally I have now Object-ified the notion of path and role:
> AttributePath and AttributeRole.
+100
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On Fri, Mar 28, 2014 at 7:06 AM, Hardy Ferentschik wrote:
>
> On 27 Jan 2014, at 23:54, Steve Ebersole wrote:
>
> > This is a bit of a potentially insidious one. Not the best way to start
> > off a discussion, I know :)
> >
> > The premise is this... Until now Hibernate has represented attribute
On 28 March 2014 12:15, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>
>> I'd then remove Log4J from our test dependencies to primarily rely on
>> assertions only;
>
> Why would you do that? I would expect whatever solution we come up with to
> just delegate to th
Hi Sanne,
On Fri, Mar 28, 2014 at 12:56 PM, Sanne Grinovero wrote:
> However - I might not have fully grasped this yet - but I'm thinking
> that this is a feature request and not a bugfix that should be hastily
> applied on 4.4.
It's not a feature request. 4.4 changed this behavior. It was worki
On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
> Given the problems using byteman is causing in CI
What problem is that?
> and the fact that our
> reliance on it is pretty light at the moment, I wanted to reach out for
> some other ideas/proposals for ways to handle this testing requirement.
On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>
>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>
>>> I'd then remove Log4J from our test dependencies to primarily rely on
>>> assertions only;
>>
>> Why would you do that? I would e
On Mar 28, 2014 7:27 AM, "Hardy Ferentschik" wrote:
>
>
> On 28 Jan 2014, at 12:47, Steve Ebersole wrote:
>
> > Given the problems using byteman is causing in CI
>
> What problem is that?
Port contention of some sort
>
> > and the fact that our
> > reliance on it is pretty light at the moment,
On 28 March 2014 12:35, Hardy Ferentschik wrote:
>
> On 28 Jan 2014, at 13:21, Sanne Grinovero wrote:
>
>> On 28 March 2014 12:15, Hardy Ferentschik wrote:
>>>
>>> On 28 Jan 2014, at 13:03, Sanne Grinovero wrote:
>>>
I'd then remove Log4J from our test dependencies to primarily rely on
>>>
Hi again,
I posted a pull request for the 4.5 branch:
https://github.com/hibernate/hibernate-search/pull/590 . Comments
welcome!
I included a rather large test case I have extracted from our app.
It's simplified but I think you should get the idea by looking at it.
All tests passes.
FWIW, I fin
Hi,
Here is a fix for the Eclipse formatter posted on the community site.
Currently, it changes:
x.foo();
to
x. foo();
which doesn't respect the checkstyle rules.
Thought it might be useful to report it as it's quite painful to have
a build broken because of that.
Thanks!
--
Guillaume
__
XWiki solved that with a JUnit rule and an in-memory log appender. I beleive
their test adds the log appender programmatically during the tests.
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-test/xwiki-commons-test-simple/src/main/java/org/xwiki/test/LogRule.
No strong feeling about it.
It will break the OGM dialects that make use of the collection role though. So
we need to anticipate.
To me . looks more like the code being used and is a natural notation even
beyond Java. But I get that # offers some additional info.
Have you considered?
org.h.
It seems we are all ok except on the SearchFactory shuffling. Not we we agree
(or disagree) on that one.
On 28 Mar 2014, at 12:41, Hardy Ferentschik wrote:
> Have we by now reached a consensus on wether or not to address the package
> split?
> Anyone against generally against it?
>
> —Hardy
>
This is not quite the same thing as what I am asking about.
I'd much rather check for the execution of a specific method
(CoreMessageLogger#idClassHadMappingAnnotations, e.g.) as opposed to a
generic method and checking one of its String arguments. We have already
had quite a bit of trouble in 5.
What we choose as a separator after the "pivot" is irrelevant to a degree,
especially in terms of the compatibility concern. I think you understood
that, just being clear. Meaning that calls like:
sessionFactoryImplementor.getCollectionPersister( "org.h.SomeEntity.nv.to.hell"
)
will fail whethe
Just for the record, upgrading to Java 1.7.0_51 fixed the build for me.
- Original Message -
> From: "Steve Ebersole"
> To: "Gail Badner"
> Cc: "Hibernate"
> Sent: Friday, March 28, 2014 4:22:35 AM
> Subject: Re: [hibernate-dev] Build failure executing
> :hibernate-core:runAnnotationPr
29 matches
Mail list logo
