What is the Entity Package used for?

when service call:
<service-call name="create#mantle.account.financial.FinancialAccount" in-map="context" out-map="context"/>
Can we write like?
<service-call name="create#FinancialAccount" in-map="context" out-map="context"/>

when service define:
<service verb="create" noun="Example" displayName="Create an Example" type="entity-auto" allow-remote="true">
Can we write?
<service verb="create" noun="moqui.example.Example" displayName="Create an Example" type="entity-auto" allow-remote="true">

If both are fine, is there any difference? If there’s no difference, why need “package”?

As of why there is a package, as far as I know, it is mainly to group related entities together, which is useful when you use e.g. the Entities screen, search for the package name and get to see all entities that share the package name. Also, the services which mainly use these entities usually have as path the same or similar name as the entity package.
If you add your own entities and use your own custom package name, it will also be useful to keep in mind where the entities were defined.
But most importantly, the services you mention are not defined explicitly but are part or the implicit “entity-auto” services, which exist for every defined entity using ‘create’, ‘update’, ‘delete’ or ‘store’ as verb, and the complete entity name as noun.

You could certainly write a service that implements these services explicitly, but I have not really seen a real-world use case where it makes a lot of sense.
Same goes for creating two different entities with same name but different package, which in theory is possible (would probably require setting a different database table name) but not sure it would be a good idea.


This is correct to my understanding.

By the way the ‘create’, ‘update’, ‘delete’, and ‘store’ services are called the auto services.

Under the hood, what happens is the mantle.account.financial.FinancialAccount is converted into a table called financial_account to preserve conventions of database / old Java OO class names. If you have another entity called your.company.example.FinancialAccount then I believe there will be a name collision at the database level. Just name your table something else.