You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Malin Nicolas <ma...@librenberry.net> on 2012/08/08 23:06:32 UTC
SlimDown, convert mini-lang CRUD service to entity-auto
With OFBiz slimDown jacopo offert to convert crud service on mini lang
to entity-auto. I start to convert crud service on marketing component,
and before continue I prefere ask if it's ok for the community to work
on this task because there is no jira slimDown version on it.
I follow this process :
1. Check minilang service, if no specific process is present, pass the
service definition on entity-auto
2. Run test to detect first problem level
3. create/update/delete entity on converted services
During the first conversion, I stop on some entities with some case :
* field lastModifiedByUserLogin, lastModifiedDate, createdByUserLogin
and createdDate are initialized on crud service.
* Some service contains only error label
I suggest to extend entity-auto engine with these fields management
since they always have the same initialisation.
Or other idea, these fields can be manage by entity-engine as
createdTimestamp as like :
<entity name="TrackingCode" follow-last-update-user="true">
....
On customer site, there is possible to extend an entity to enable a
first history level
Your opinion ?
Nicolas
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Nicolas,
From: "Nicolas Malin" <ma...@librenberry.net>
>> Why did you suggest to
>>> * remove all fields created/lastModified from entities definition
>>> and use an attribute on entity tag as like '<entity
>>> name="QuoteAdjustment" auto-created-last-modified="true">
>> ? This would be a major disruptment and I don't get the reason for it
> A reasoning on a up level. First proposition is to correct and
> homogenize entities but last/created fields would be manage only by
> service, and the reason to work directly by entity-auto. The pattern has
> been always the same.
> I see the advantage :
> * simple analyse bu modelEntity.isAutoCreatedLastModified() instead of
> modelEntity.hasField("createdUserLogin") && ...
> * simple to extend <extend-entity entity-name="InvoiceItem"
> auto-created-last-modified="true"> instead of <extend-entity
> entity-name="InvoiceItem"><field name="createdUserLogin" >....
> * simple to improve
>
> I don't see what disruptment would be generate by this idea
If ever someone has used those fields in code.
Jacques
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 07/09/2012 07:51, Jacques Le Roux a écrit :
> HI Nicolas,
>
> Since we did not get any feedback
harm
> I suggest to
> * add missing created fields on ValueLinkKey
> * take into account lastUpdate fields in ShipmentRouteSegment as a
> field to handle in entity-auto as the same purpose (easier than
> migrating IMO)
> * add lastModified fields on QuoteAdjustment, OrderAdjustment,
> ReturnAdjustment and OrderPaymentPreference
Ok just adding code, no modification.
>
> Why did you suggest to
>> * remove all fields created/lastModified from entities definition
>> and use an attribute on entity tag as like '<entity
>> name="QuoteAdjustment" auto-created-last-modified="true">
> ? This would be a major disruptment and I don't get the reason for it
A reasoning on a up level. First proposition is to correct and
homogenize entities but last/created fields would be manage only by
service, and the reason to work directly by entity-auto. The pattern has
been always the same.
I see the advantage :
* simple analyse bu modelEntity.isAutoCreatedLastModified() instead of
modelEntity.hasField("createdUserLogin") && ...
* simple to extend <extend-entity entity-name="InvoiceItem"
auto-created-last-modified="true"> instead of <extend-entity
entity-name="InvoiceItem"><field name="createdUserLogin" >....
* simple to improve
I don't see what disruptment would be generate by this idea, but your
right at first one step :)
I will adding missing fields and analysis on jira
Nicolas
>
> Thanks
>
> Jacques
>
> From: "Nicolas Malin" <ma...@librenberry.net>
>> Hi,
>>
>> With Jacques, we checked ofbiz data model to sure that all case would
>> be manage by entity-auto for fields [created/lastModified]Date and
>> [created/lastModified]ByUserLogin present on some entities.
>>
>> We found :
>> * QuoteAdjustment, OrderAdjustment, ReturnAdjustment and
>> OrderPaymentPreference with only created fields but isn't a problem.
>> * ValueLinkKey have only lastModified fields (missing created)
>> * ShipmentRouteSegment don't use lastModifiedDate,
>> lastModifiedByUserLogin but lastUpdateDate, updateByUserLogin.
>>
>> We have many solution :
>> * keep entities like that
>> * add just missing created fields on ValueLinkKey
>> * migrate lastUpdate fields to lastModified on ShipmentRouteSegment
>> * adding lastModified fields on QuoteAdjustment, OrderAdjustment,
>> ReturnAdjustment and OrderPaymentPreference
>> * remove all fields created/lastModified from entities definition
>> and use an attribute on entity tag as like '<entity
>> name="QuoteAdjustment" auto-created-last-modified="true">
>>
>> Your opinions ?
>>
>>> Le 09/08/2012 08:48, Jacques Le Roux a écrit :
>>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>>> On 8/8/2012 10:06 PM, Malin Nicolas wrote:
>>>>>> I suggest to extend entity-auto engine with these fields
>>>>>> management since they always have the same initialisation.
>>>>>
>>>>> That sounds like a good enhancement.
>>>>>
>>>>> -Adrian
>>>>
>>>> +1, well spotted Nicolas, we must be sure to not miss any fields
>>>> like this. Could there be other cases with incrementation or such?
>>> Other case will be found during the migration :) .
>>>
>>>>
>>>> What was the pb when only error label? I think we can migrate them
>>>> keeping the error messages, right? Or should we get rid of them
>>>> and have something generalised? Or should we add error message to
>>>> such migrated services? Just thinking aloud here, not really awake
>>>> yet ;o)
>>> :) I check if is possible to manage error message en entity-auto.
>>> Pending, I will open a jira isssue to load my patch on the last
>>> proposal.
>>>
>>>
>>>>
>>>> Jacques
>>>
>>
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Jacques Le Roux <ja...@les7arts.com>.
HI Nicolas,
Since we did not get any feedback I suggest to
* add missing created fields on ValueLinkKey
* take into account lastUpdate fields in ShipmentRouteSegment as a field to handle in entity-auto as the same purpose (easier than
migrating IMO)
* add lastModified fields on QuoteAdjustment, OrderAdjustment, ReturnAdjustment and OrderPaymentPreference
Why did you suggest to
> * remove all fields created/lastModified from entities definition and use an attribute on entity tag as like '<entity
> name="QuoteAdjustment" auto-created-last-modified="true">
? This would be a major disruptment and I don't get the reason for it
Thanks
Jacques
From: "Nicolas Malin" <ma...@librenberry.net>
> Hi,
>
> With Jacques, we checked ofbiz data model to sure that all case would be manage by entity-auto for fields
> [created/lastModified]Date and [created/lastModified]ByUserLogin present on some entities.
>
> We found :
> * QuoteAdjustment, OrderAdjustment, ReturnAdjustment and OrderPaymentPreference with only created fields but isn't a problem.
> * ValueLinkKey have only lastModified fields (missing created)
> * ShipmentRouteSegment don't use lastModifiedDate, lastModifiedByUserLogin but lastUpdateDate, updateByUserLogin.
>
> We have many solution :
> * keep entities like that
> * add just missing created fields on ValueLinkKey
> * migrate lastUpdate fields to lastModified on ShipmentRouteSegment
> * adding lastModified fields on QuoteAdjustment, OrderAdjustment, ReturnAdjustment and OrderPaymentPreference
> * remove all fields created/lastModified from entities definition and use an attribute on entity tag as like '<entity
> name="QuoteAdjustment" auto-created-last-modified="true">
>
> Your opinions ?
>
>> Le 09/08/2012 08:48, Jacques Le Roux a écrit :
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>> On 8/8/2012 10:06 PM, Malin Nicolas wrote:
>>>>> I suggest to extend entity-auto engine with these fields management since they always have the same initialisation.
>>>>
>>>> That sounds like a good enhancement.
>>>>
>>>> -Adrian
>>>
>>> +1, well spotted Nicolas, we must be sure to not miss any fields like this. Could there be other cases with incrementation or
>>> such?
>> Other case will be found during the migration :) .
>>
>>>
>>> What was the pb when only error label? I think we can migrate them keeping the error messages, right? Or should we get rid of
>>> them
>>> and have something generalised? Or should we add error message to such migrated services? Just thinking aloud here, not really
>>> awake
>>> yet ;o)
>> :) I check if is possible to manage error message en entity-auto. Pending, I will open a jira isssue to load my patch on the last
>> proposal.
>>
>>
>>>
>>> Jacques
>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Nicolas Malin <ma...@librenberry.net>.
Hi,
With Jacques, we checked ofbiz data model to sure that all case would be
manage by entity-auto for fields [created/lastModified]Date and
[created/lastModified]ByUserLogin present on some entities.
We found :
* QuoteAdjustment, OrderAdjustment, ReturnAdjustment and
OrderPaymentPreference with only created fields but isn't a problem.
* ValueLinkKey have only lastModified fields (missing created)
* ShipmentRouteSegment don't use lastModifiedDate,
lastModifiedByUserLogin but lastUpdateDate, updateByUserLogin.
We have many solution :
* keep entities like that
* add just missing created fields on ValueLinkKey
* migrate lastUpdate fields to lastModified on ShipmentRouteSegment
* adding lastModified fields on QuoteAdjustment, OrderAdjustment,
ReturnAdjustment and OrderPaymentPreference
* remove all fields created/lastModified from entities definition and
use an attribute on entity tag as like '<entity name="QuoteAdjustment"
auto-created-last-modified="true">
Your opinions ?
> Le 09/08/2012 08:48, Jacques Le Roux a écrit :
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> On 8/8/2012 10:06 PM, Malin Nicolas wrote:
>>>> I suggest to extend entity-auto engine with these fields management
>>>> since they always have the same initialisation.
>>>
>>> That sounds like a good enhancement.
>>>
>>> -Adrian
>>
>> +1, well spotted Nicolas, we must be sure to not miss any fields like
>> this. Could there be other cases with incrementation or such?
> Other case will be found during the migration :) .
>
>>
>> What was the pb when only error label? I think we can migrate them
>> keeping the error messages, right? Or should we get rid of them
>> and have something generalised? Or should we add error message to
>> such migrated services? Just thinking aloud here, not really awake
>> yet ;o)
> :) I check if is possible to manage error message en entity-auto.
> Pending, I will open a jira isssue to load my patch on the last proposal.
>
>
>>
>> Jacques
>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Malin Nicolas <ma...@librenberry.net>.
Le 09/08/2012 08:48, Jacques Le Roux a écrit :
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> On 8/8/2012 10:06 PM, Malin Nicolas wrote:
>>> I suggest to extend entity-auto engine with these fields management
>>> since they always have the same initialisation.
>>
>> That sounds like a good enhancement.
>>
>> -Adrian
>
> +1, well spotted Nicolas, we must be sure to not miss any fields like
> this. Could there be other cases with incrementation or such?
Other case will be found during the migration :) .
>
> What was the pb when only error label? I think we can migrate them
> keeping the error messages, right? Or should we get rid of them
> and have something generalised? Or should we add error message to such
> migrated services? Just thinking aloud here, not really awake
> yet ;o)
:) I check if is possible to manage error message en entity-auto.
Pending, I will open a jira isssue to load my patch on the last proposal.
>
> Jacques
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@sandglass-software.com>
> On 8/8/2012 10:06 PM, Malin Nicolas wrote:
>> With OFBiz slimDown jacopo offert to convert crud service on mini lang to entity-auto. I start to convert crud service on
>> marketing component, and before continue I prefere ask if it's ok for the community to work on this task because there is no jira
>> slimDown version on it.
>>
>> I follow this process :
>> 1. Check minilang service, if no specific process is present, pass the service definition on entity-auto
>> 2. Run test to detect first problem level
>> 3. create/update/delete entity on converted services
>>
>> During the first conversion, I stop on some entities with some case :
>> * field lastModifiedByUserLogin, lastModifiedDate, createdByUserLogin and createdDate are initialized on crud service.
>> * Some service contains only error label
>>
>> I suggest to extend entity-auto engine with these fields management since they always have the same initialisation.
>
> That sounds like a good enhancement.
>
> -Adrian
+1, well spotted Nicolas, we must be sure to not miss any fields like this. Could there be other cases with incrementation or such?
What was the pb when only error label? I think we can migrate them keeping the error messages, right? Or should we get rid of them
and have something generalised? Or should we add error message to such migrated services? Just thinking aloud here, not really awake
yet ;o)
Jacques
Re: SlimDown, convert mini-lang CRUD service to entity-auto
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 8/8/2012 10:06 PM, Malin Nicolas wrote:
> With OFBiz slimDown jacopo offert to convert crud service on mini lang
> to entity-auto. I start to convert crud service on marketing
> component, and before continue I prefere ask if it's ok for the
> community to work on this task because there is no jira slimDown
> version on it.
>
> I follow this process :
> 1. Check minilang service, if no specific process is present, pass
> the service definition on entity-auto
> 2. Run test to detect first problem level
> 3. create/update/delete entity on converted services
>
> During the first conversion, I stop on some entities with some case :
> * field lastModifiedByUserLogin, lastModifiedDate, createdByUserLogin
> and createdDate are initialized on crud service.
> * Some service contains only error label
>
> I suggest to extend entity-auto engine with these fields management
> since they always have the same initialisation.
That sounds like a good enhancement.
-Adrian