Yes, verbs might not work well esp since JPA does not use that style.
I kinda liked the vibe :)
On Mon 2013-12-16 17:24, Gunnar Morling wrote:
> 2013/12/16 Emmanuel Bernard
>
> > I think in this specific case it does make sense to have a global
> > setting and a specific one for the additional m
2013/12/16 Emmanuel Bernard
> On Mon 2013-12-16 11:06, Gunnar Morling wrote:
> > 2013/12/13 Emmanuel Bernard
> >
> > > So currently in the pull request, we now have the following
> > >
> > > 1. property > entity > global
> > > 2. for each level in 1., programmatic API beats annotation
> > >
> >
2013/12/16 Emmanuel Bernard
> I think in this specific case it does make sense to have a global
> setting and a specific one for the additional mongodb if we rephrase
> then like think
>
> @StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be
> AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY)
> @Sto
I think in this specific case it does make sense to have a global
setting and a specific one for the additional mongodb if we rephrase
then like think
@StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be AS_SEPARATE_DOCUMENT
or AS_SEPARATE_ENTRY)
@StoreAssociationsInSeparateCollection //mongo
On Mon 2013-12-16 11:06, Gunnar Morling wrote:
> 2013/12/13 Emmanuel Bernard
>
> > So currently in the pull request, we now have the following
> >
> > 1. property > entity > global
> > 2. for each level in 1., programmatic API beats annotation
> >
> > These are simple rules to understand and all
> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.
I agree with emmanuel on this one.
I think I would be surprise to see that the annotation
2013/12/16 Guillaume SCHEIBEL
> My opinion is that each provider "provides" its own set of options. If
> some of them exist in multiple providers they should have the name so we
> won't disturb users.
>
Just to be sure, did you mean to say "... should have the *same* name..."?
Note that the mot
My opinion is that each provider "provides" its own set of options. If some
of them exist in multiple providers they should have the name so we won't
disturb users.
My 2 cents :)
Guillaume
2013/12/16 Gunnar Morling
> > Only the CouchDB provider in the PR so far. But the idea is to move all
> t
2013/12/13 Emmanuel Bernard
> So currently in the pull request, we now have the following
>
> 1. property > entity > global
> 2. for each level in 1., programmatic API beats annotation
>
> These are simple rules to understand and all it good.
>
> Now Gunnar tried to handle class inheritance, ie s
> Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.
Right; I've a local branch where I had started with @AssociationStorage
support for MongoDB, but focused on CouchDB then.
On a related note, Emmanuel raised the question whether to use the same
option types f
Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.
On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> Hi guys,
>
> That sounds nice. Are association storage strategies already using this new
> feature ?
>
>
> Guillaume
>
>
> 2013/12/13 Emmanuel Bernard
>
Hi guys,
That sounds nice. Are association storage strategies already using this new
feature ?
Guillaume
2013/12/13 Emmanuel Bernard
> So currently in the pull request, we now have the following
>
> 1. property > entity > global
> 2. for each level in 1., programmatic API beats annotation
>
So currently in the pull request, we now have the following
1. property > entity > global
2. for each level in 1., programmatic API beats annotation
These are simple rules to understand and all it good.
Now Gunnar tried to handle class inheritance, ie superclasses and overridden
methods.
And we
2013/12/4 Emmanuel Bernard
> On Wed 2013-12-04 10:33, Gunnar Morling wrote:
> > 2013/12/3 Emmanuel Bernard
> >
> > > On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > > > Thanks, Davide.
> > > >
> > > > 2013/12/3 Davide D'Alto
> > > >
> > > > > It looks good to me.
> > > > >
> > > >
> > > > Ok
On Wed 2013-12-04 10:33, Gunnar Morling wrote:
> 2013/12/3 Emmanuel Bernard
>
> > On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > > Thanks, Davide.
> > >
> > > 2013/12/3 Davide D'Alto
> > >
> > > > It looks good to me.
> > > >
> > >
> > > Ok.
> > >
> > > > I first didn't like that but I came
2013/12/3 Davide D'Alto
> If I understand correctly, What you are suggesting instead, it is to have
> two different names for the same property (), defaultHost in the
> persistence.xml and host in the API, this means that I have to know how to
> call a property based on the place where I want to
2013/12/3 Emmanuel Bernard
> On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> > Thanks, Davide.
> >
> > 2013/12/3 Davide D'Alto
> >
> > > It looks good to me.
> > >
> >
> > Ok.
> >
> > > I first didn't like that but I came to think it makes sense, if the
> > > property name conveys that semantic
2013/12/3 Emmanuel Bernard
> I am quite uncomfortable with that approach.
>
> Here is what I propose instead (we did discuss that in the past a bit).
>
> Rules by decreasing precedence:
>
> property | association > class > super class > global
> (*) question: what about overridden properties
>
>
On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> Thanks, Davide.
>
> 2013/12/3 Davide D'Alto
>
> > It looks good to me.
> >
>
> Ok.
>
> > I first didn't like that but I came to think it makes sense, if the
> > property name conveys that semantics, e.g. "defaultAssociationStorageMode".
> >
> >
I am quite uncomfortable with that approach.
Here is what I propose instead (we did discuss that in the past a bit).
Rules by decreasing precedence:
property | association > class > super class > global
(*) question: what about overridden properties
For a given level mentioned above,
API > ann
If I understand correctly, What you are suggesting instead, it is to have
two different names for the same property (), defaultHost in the
persistence.xml and host in the API, this means that I have to know how to
call a property based on the place where I want to set it. This is
confusing for me.
Thanks, Davide.
2013/12/3 Davide D'Alto
> It looks good to me.
>
Ok.
> I first didn't like that but I came to think it makes sense, if the
> property name conveys that semantics, e.g. "defaultAssociationStorageMode".
>
> I don't think it's necessary to use the prefix "default". For me it is
>
Hi,
In the context of embedded associations for CouchDB [1], I'm working on
support for configuring the association storage mode using our new option
system [2]. I can see the following "axes" of configuration here:
* via annotation
- on an association property
- on a type
* via the option AP
23 matches
Mail list logo
