Hi,

When removing an object, DN only uses TenantId, while it uses the tenant-read-ids when querying.

// Tenants : John,Chris
final Query query = entityManager.createQuery("select e from Element e ");
final List resultList = query.getResultList();
for (Object o : resultList)
{
    entityManager.remove(o);
}
transaction.commit();

SELECT 'net.nature.Element' AS `DN_TYPE`,`E`.`ID`,`E`.`NAME` FROM `ELEMENT` `E` WHERE `E`.`TENANT` IN('John','Chris')
DELETE FROM `ELEMENT` WHERE `ID`=<1614949869149> AND `TENANT`=<'NULL'> ...


As I haven't found in the docs yet how it should work.

The DELETE should be :
1- if Tenant is not part of the identifier and we somewhat strict:
DELETE FROM `ELEMENT` WHERE `ID`=<1614949869149> AND `TENANT`IN('John','Chris') ...
2- if looking at the value of the tenant of this object, we can be very strict
DELETE FROM `ELEMENT` WHERE `ID`=<1614949869149> AND `TENANT`= 'John'
3- if we're a little less strict and tenant is not part of the id (just as it is for updates):
DELETE FROM `ELEMENT` WHERE `ID`=<1614949869149>
Update example:
UPDATE `ELEMENT` SET `NAME`=<'Aluminum 1614949877211 1614950377268'> WHERE `ID`=<1614949869149>

I think DeleteRequest can make use of getTenantReadIds while it only uses getTenantId.

if (multitenancyStatementMapping != null)
{
    table.getSurrogateMapping(SurrogateColumnType.MULTITENANCY, false).setObject(ec, ps, 
        multitenancyStatementMapping.getParameterPositionsForOccurrence(0), ec.getNucleusContext().getMultiTenancyId(ec));
}

Considering the case 3, may mean to remove the code above... 

--
Stephane

A DELETE is not a READ. Hence "tenantReadIds" is not for use on a DELETE (or on an INSERT, or an UPDATE). That is the DataNucleus feature definition.
Doesn't mean that is the feature you want.

As tenant-read-ids is not used for UPDATES, but is used for DELETES I've thought something was forgotten... 

The feature I'm putting in place is to "partition" some data. Then users can access to the data of all the partitions they belong to.

So Multitenancy seems to perfectly fulfill the partitioning and the tenant-read-ids features potentially offer a great flexibility, but, flexibility bring big complexities which I want to evaluate:
- How select,insert,update,delete works on simple objects 
- How do they works on relationship loading
- How L2 cache behave with this feature ?
...