2015-03-26 0:21 GMT+01:00 Steve Ebersole :
> 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
2015-03-26 3:56 GMT+01:00 Steve Ebersole :
> 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()
>
Ah, I forgot you cannot rely on Java 8 yet ;)
Interesting, Neo4J 2.2 now does unified commits like we do in Hibernate Search
to get several transactions per disk flush in Lucene.
http://neo4j.com/blog/neo4j-2-2-0-scalability-performance/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
Interesting, glad we have prior art ;)
They seem to have gone a step further though: a single unified commit
of Neo4J includes both the data and the index changesets. We still
have to figure out how to better integrate the index changes with the
database transaction; although that's only interesti
Hi Adam,
We did discuss it and we don’t feel like we have the bandwidth this year to
mentor a Google Summer of Code student. We would do them a disservice. So we
will pass this year.
Emmanuel
> On 22 Mar 2015, at 09:28, Adam Stawicki wrote:
>
> Do we still have enough time to suggest an addi
I'm not so convinced that we need this additional level of instantiation
just to avoid exposing access to the collected sources (getters).
Anyone else have opinions on this?
On Thu, Mar 26, 2015 at 3:35 AM, Gunnar Morling
wrote:
> 2015-03-26 3:56 GMT+01:00 Steve Ebersole :
>
>> On second though
[adding the mailing list]
Generally speaking, looks like we agree on the direction: EntityEntry
needs to be an interface, and some clever logic to select the
appropriate implementations.
In your draft you're having a single EntityEntryFactory as a global
service; I'm wondering if we shouldn't have
Forcing 3 is correct but rarely desirable, I'm afraid the user should choose.
But most people will not like the additional
space/performance/complexity hit, and will use a single timezone.
If you think we should force people into a correct choice, you'd
require 3# unless they are willing to set a
Thanks for your thoughts Sanne. I am going to break my responses down into
digestable chunks to follow...
On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
wrote:
> [adding the mailing list]
>
> Generally speaking, looks like we agree on the direction: EntityEntry
> needs to be an interface, a
On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
wrote:
>
>
> Concurrency
>Since the goal is to share the ImmutableEntityEntry instance among
> multiple threads reading it, I'd rather make sure that it is really
> immutable. For example it now holds onto potentially lazy initialized
> fields,
Apparently I hit some key combo that means send :) To finish up...
On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole
wrote:
>
> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
> wrote:
>>
>>
>> Concurrency
>>Since the goal is to share the ImmutableEntityEntry instance among
>> multiple th
The contract I suggested btw is missing one use case I know we have
discussed in regards to OGM a few times... the ability to store references
to datastore specific locators (I think the use case was to efficiently
load collections through that datastore reference). But that (obviously)
requires p
Now the "meat"...
On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
wrote:
>
>
> What is your primary differentiator between 'SharedEntityEntry' and
> 'StatefulEntityEntry' ?
> For our purposes I'd have used different names, but since there's no
> javadoc yet I wonder if you had different intenti
The real difficulty with (3) is querying. How do you restrict a query on a
(TIMESTAMP,TZ) tuple for example when the individual values could be in
multiple timezones? Andrea and I were just discussing the same in regards
to Java 9(?) Money/Currency support.
Personally I think this idea of trying
2015-03-26 15:56 GMT+01:00 Steve Ebersole :
> I'm not so convinced that we need this additional level of instantiation
> just to avoid exposing access to the collected sources (getters).
>
Few things are strictly needed in the end :)
IMO limiting the exposed API as much as possible is a good thi
15 matches
Mail list logo
