I guess it is an oversight. Please open a ticket. The 2.0 merge is so
extensive, that I will need to re-implement it anyway, so if you
attach a testcase, it would be even better.
That said, a quick look at the sources, and I suspect that a
put("abc", null) would work, as it is backed by a HashMap.
-- Niclas
On Thu, Aug 25, 2011 at 12:50 PM, Chris Chapman
<[email protected]> wrote:
> On Sat 14 May 2011 10:12:09 PM MDT, Niclas Hedhman (JIRA) wrote:
>> [
>> http://issues.ops4j.org/browse/QI-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197#action_14197
>> ]
>>
>> Niclas Hedhman commented on QI-301:
>> -----------------------------------
>>
>> I would like to suggest the name "NamedAssociation", since we are
>> effectively putting a name on to the association itself.
>>
>>> Better support for "Entity Local" identities
>>> --------------------------------------------
>>>
>>> Key: QI-301
>>> URL: http://issues.ops4j.org/browse/QI-301
>>> Project: Qi4j
>>> Issue Type: New Feature
>>> Components: API, Core Runtime
>>> Affects Versions: 1.2
>>> Reporter: Niclas Hedhman
>>> Assignee: Rickard Öberg
>>> Fix For: Unknown
>>>
>>>
>>> Currently it is possible to have design time defined "local identities" for
>>> referenced entities, simply as;
>>> {code}
>>> public interface Car
>>> {
>>> Association<Tyre> frontRightTyre();
>>> }
>>> {code}
>>> But if the list is not known at design time, things quickly becomes more
>>> troublesome (and potentially slower, depending on how one approaches it).
>>> One can either do a ManyAssociation;
>>> {code}
>>> public interface Family
>>> {
>>> ManyAssociation<Child> kids();
>>> }
>>> {code}
>>> and loop through, but if the numbers get very large one needs to start
>>> mangling with Identity composition
>>> {code}
>>> public interface CompanyDivision
>>> {
>>> Property<Map<String,String>> employees();
>>> }
>>> {code}
>>> where first String of local identity (within the company) maps to a global
>>> Identity of some non-obvious type. There is also the choice of using Query,
>>> but that kills performance in a big way.
>>> I come across this on every front right now, and not happy with the
>>> Identity mangling approach, and would like to call for direct support in
>>> Qi4j.
>>> Proposal;
>>> At the user side of the equation, something like this should be possible;
>>> {code}
>>> public interface CompanyDivision
>>> {
>>> KeydAssociation<Employee> employees();
>>> }
>>> {code}
>>> And the KeydAssociation (better name is probably needed) interface would be
>>> something like this;
>>> {code}
>>> public interface KeydAssociation<T> extends Iterable<T>, AbstractAssociation
>>> {
>>> void put( String key, T entity );
>>> T get( String key );
>>> int count();
>>> boolean containsKey( String key );
>>> boolean contains( T entity );
>>> Map<String, T> toMap();
>>> }
>>> {code}
>>> This should then be supported at EntityStore level as well, similarly to
>>> ManyAssociation.
>
> Any reason why NamedAssociation<T> does not include remove( T Entity )?
> I see that NamedAssociationInstance<T> includes the method, but the
> interface does not.
>
> Regards,
> Chris Chapman
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
