You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Taher Alkhateeb <sl...@gmail.com> on 2017/05/01 07:03:37 UTC
Re: Difference between "id" and "id-ne" field type
I don't have the historical context, so please excuse if I'm off.
My recommendation is to reintroduce the validation attribute. However! the
validation IMO should happen at the entity engine level, not the database
level (for not null), and also the default value should be false if
omitted. We also need to think of the design in respect of the validation
attributes and how they apply.
On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
aditya.sharma@hotwaxsystems.com> wrote:
> Hi,
>
> While creating an entity I was in ambiguity whether to go for "*id*" or "
> *id-ne*" field type. When I googled it I came across this very enriching
> discussion.
>
> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-td2251546.html
>
> As stated, an "id-ne" field can only have a *non-empty* value.
>
> I was very curious to know how it is implemented in OFBiz. I found that
> almost all the *fieldtype*.xml* files have *same* *sql-type* and
> *java-type*
> for these 2 field types but I couldn't get any trace of how that not-empty
> constraint is levied upon "id-ne" fields.
>
> I even looked at table structure for those fields having "id-ne" field type
> but there was no "not-null" constraint at even the database level.
>
> When dug into it further I can across this commit where validate elements
> were removed from fieldtype*.xml files.
>
>
> http://markmail.org/message/otec62xiwkpjttkq
>
> http://svn.apache.org/viewvc?view=revision&revision=959708
>
> But I can't get why it was removed and when it was removed whether there
> was some implementation that took its place for those validations.
>
>
> To further check if it even works I found an OOTB entity having a
> non-primary key "id-ne" field. I found that "*Picklist*" entity has a field
> *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist* for an
> order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
>
>
> If my explorations are correct currently there is no difference between
> "id" and "id-ne" at the implementation level and there should be a Jira for
> it.
>
> If I missed out something, can someone please enlighten me with that and
> help me understanding it well.
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
Re: Difference between "id" and "id-ne" field type
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
Thanks, Jacques :)
That elucidates it quite well now.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Mon, May 8, 2017 at 6:15 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi Aditya,
>
> Done, please check
>
> Jacques
>
>
> Le 08/05/2017 à 11:49, Aditya Sharma a écrit :
>
>> I have created the ticket for it OFBIZ-9351
>> <https://issues.apache.org/jira/browse/OFBIZ-9351>.
>>
>> Jacques, Can you please elaborate some more on it.
>>
>> When replacing id-ne alike fields by id alike we should add the
>> "not-null"
>>
>>> attribute.
>>>
>>
>> For those fields where it requires not-empty fields values, we will be
>> implementing a new not-null attribute.
>>
>> Thanks & Regards,
>> Aditya Sharma
>> Enterprise Software Engineer
>> HotWax Systems Pvt. Ltd.
>> http://www.hotwaxsystems.com/
>>
>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>
>>
>> On Mon, May 8, 2017 at 1:55 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Please Aditya create a Jira for that.
>>>
>>> Something I forgot to clearly mention. When replacing id-ne alike fields
>>> by id alike we should add the "not-null" attribute.
>>>
>>> Jacques
>>>
>>>
>>> Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
>>>
>>> Thanks Scott for the link :)
>>>>
>>>> It completely makes sense to me now with what David said there.
>>>>
>>>> They are intentionally not used in other parts of the project as
>>>> validation
>>>>
>>>> is
>>>>> best in the logic layer, and not in the data layer
>>>>>
>>>>> If those field types serve no purpose then it is better to remove them
>>>>>
>>>> to avoid any future confusions.
>>>>
>>>> Can I start working towards it then?
>>>>
>>>>
>>>> Thanks & Regards,
>>>> Aditya Sharma
>>>> Enterprise Software Engineer
>>>> HotWax Systems Pvt. Ltd.
>>>> http://www.hotwaxsystems.com/
>>>>
>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>
>>>>
>>>> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Thanks Guys for the links,
>>>>
>>>>> I also agree we can now remove the useless id-ne, id-long-ne and
>>>>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>>>>> We also need to clean the related embedded documentation. Like for
>>>>> instance for "not-null" in fieldtypemodel.xsd
>>>>> For the rest let it be, I don't think there is much more documentation
>>>>> about that anyway.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>>>>
>>>>> Chances are the field type was left for backwards compatibility. I'm
>>>>> ok
>>>>>
>>>>>> with it being removed though.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hmmm I was actually rethinking about this, and this reminds me
>>>>>> somewhat
>>>>>> of
>>>>>>
>>>>>> the "Bounded context" concept from DDD. Some services might want to
>>>>>>> validate while others don't on certain fields depending on context,
>>>>>>> and
>>>>>>> hence delegating that validation to services makes sense (no domain
>>>>>>> exists
>>>>>>> in OFBiz).
>>>>>>>
>>>>>>> The problem of the existence of id-ne lingers though. It's putting
>>>>>>> unneceasary cognitive strain on users to figure out what is it and
>>>>>>> what
>>>>>>> to
>>>>>>> do with it. Also, this means no validation can happen for entity-auto
>>>>>>> CRUD
>>>>>>> services.
>>>>>>>
>>>>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne,
>>>>>>> but
>>>>>>> I
>>>>>>> think we must choose one of:
>>>>>>> 1- removing id-ne
>>>>>>> 2- reintroducing validation
>>>>>>>
>>>>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Took a while to dig it out but here it is:
>>>>>>>
>>>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>>>>
>>>>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed
>>>>>>>> all
>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>> same.
>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 3 May 2017 at 17:42, Aditya Sharma <aditya.sharma@hotwaxsystems.c
>>>>>>>> om>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Scott,
>>>>>>>>
>>>>>>>> As there is very less information available with the commit I found
>>>>>>>>> it
>>>>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>>>>
>>>>>>>>> something.
>>>>>>>>>
>>>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Aditya Sharma
>>>>>>>>> Enterprise Software Engineer
>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>
>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>
>>>>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Taher,
>>>>>>>>>
>>>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>>>>
>>>>>>>>>> default
>>>>>>>>>>
>>>>>>>>> to
>>>>>>>>
>>>>>>>> false as that way it will not affect the current implementations and
>>>>>>>>
>>>>>>>>> will
>>>>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>>>>
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>> However!
>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>>
>>>>>>>>>>> database
>>>>>>>>>>>
>>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>> if
>>>>>>>>>>
>>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>>>>
>>>>>>>>>>> validation
>>>>>>>>>>>
>>>>>>>>>> attributes and how they apply.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>
>>>>>>>>>> Aditya Sharma
>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>
>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>>>>
>>>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> It was removed purposefully and there was a discussion about it.
>>>>>>>>>> I'd
>>>>>>>>>>
>>>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>>>>
>>>>>>>>>>> deciding
>>>>>>>>>>>
>>>>>>>>>> how to proceed.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <
>>>>>>>>>>> slidingfilaments@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>>>
>>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>>>
>>>>>>>>>>>> However!
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>>
>>>>>>>>>>> database
>>>>>>>>>>>>
>>>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>>>
>>>>>>>>>>>> if
>>>>>>>>>>>>
>>>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>>>
>>>>>>>>> validation
>>>>>>>>>
>>>>>>>>>> attributes and how they apply.
>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>>>>
>>>>>>>>>>>>> "*id*"
>>>>>>>>>>>>>
>>>>>>>>>>>> or "
>>>>>>>>>>>
>>>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>>>
>>>>>>>>>>> enriching
>>>>>>>>>>>> discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>>>>
>>>>>>>>>>>>> td2251546.html
>>>>>>>>>>>>>
>>>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>>>
>>>>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>>>>
>>>>>>>>>>>>> found
>>>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>
>>>>>>>>>> *java-type*
>>>>>>>>>>>>> for these 2 field types but I couldn't get any trace of how
>>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>>> not-empty
>>>>>>>>>>>>>
>>>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>>>
>>>>>>>>>>>>> I even looked at table structure for those fields having
>>>>>>>>>>>>> "id-ne"
>>>>>>>>>>>>>
>>>>>>>>>>>>> field
>>>>>>>>>>>>>
>>>>>>>>>>>> type
>>>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>>
>>>>>>>>>>>> level.
>>>>>>>>>>>>>
>>>>>>>>>>>> When dug into it further I can across this commit where validate
>>>>>>>>>>>
>>>>>>>>>> elements
>>>>>>>>>
>>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>>>
>>>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>>>>
>>>>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>>>>
>>>>>>>>>>>>> whether
>>>>>>>>>>>>>
>>>>>>>>>>>> there
>>>>>>>>>>>
>>>>>>>>>> was some implementation that took its place for those
>>>>>>>>>
>>>>>>>>>> validations.
>>>>>>>>>>>>
>>>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>>>>
>>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>>>>>>
>>>>>>>>>> has
>>>>>>>>>
>>>>>>>>>> a
>>>>>>>>>>>
>>>>>>>>>> field
>>>>>>>>>
>>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>>
>>>>>>>>>>>> picklist*
>>>>>>>>>>>>>
>>>>>>>>>>>> for
>>>>>>>>>>>
>>>>>>>>>> an
>>>>>>>>>>
>>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>>>
>>>>>>>>>>>>> *empty*.
>>>>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>>>>
>>>>>>>>>>>>> between
>>>>>>>>>>>>>
>>>>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>>>>> be a
>>>>>>>>>>>>
>>>>>>>>>>>> Jira
>>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>> it.
>>>>>>>>>>>>
>>>>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>>>>
>>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>> help me understanding it well.
>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>> Aditya Sharma
>>>>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
Re: Difference between "id" and "id-ne" field type
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Aditya,
Done, please check
Jacques
Le 08/05/2017 à 11:49, Aditya Sharma a écrit :
> I have created the ticket for it OFBIZ-9351
> <https://issues.apache.org/jira/browse/OFBIZ-9351>.
>
> Jacques, Can you please elaborate some more on it.
>
> When replacing id-ne alike fields by id alike we should add the "not-null"
>> attribute.
>
> For those fields where it requires not-empty fields values, we will be
> implementing a new not-null attribute.
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Mon, May 8, 2017 at 1:55 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Please Aditya create a Jira for that.
>>
>> Something I forgot to clearly mention. When replacing id-ne alike fields
>> by id alike we should add the "not-null" attribute.
>>
>> Jacques
>>
>>
>> Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
>>
>>> Thanks Scott for the link :)
>>>
>>> It completely makes sense to me now with what David said there.
>>>
>>> They are intentionally not used in other parts of the project as
>>> validation
>>>
>>>> is
>>>> best in the logic layer, and not in the data layer
>>>>
>>>> If those field types serve no purpose then it is better to remove them
>>> to avoid any future confusions.
>>>
>>> Can I start working towards it then?
>>>
>>>
>>> Thanks & Regards,
>>> Aditya Sharma
>>> Enterprise Software Engineer
>>> HotWax Systems Pvt. Ltd.
>>> http://www.hotwaxsystems.com/
>>>
>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>
>>>
>>> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Thanks Guys for the links,
>>>> I also agree we can now remove the useless id-ne, id-long-ne and
>>>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>>>> We also need to clean the related embedded documentation. Like for
>>>> instance for "not-null" in fieldtypemodel.xsd
>>>> For the rest let it be, I don't think there is much more documentation
>>>> about that anyway.
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>>>
>>>> Chances are the field type was left for backwards compatibility. I'm ok
>>>>> with it being removed though.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hmmm I was actually rethinking about this, and this reminds me somewhat
>>>>> of
>>>>>
>>>>>> the "Bounded context" concept from DDD. Some services might want to
>>>>>> validate while others don't on certain fields depending on context, and
>>>>>> hence delegating that validation to services makes sense (no domain
>>>>>> exists
>>>>>> in OFBiz).
>>>>>>
>>>>>> The problem of the existence of id-ne lingers though. It's putting
>>>>>> unneceasary cognitive strain on users to figure out what is it and what
>>>>>> to
>>>>>> do with it. Also, this means no validation can happen for entity-auto
>>>>>> CRUD
>>>>>> services.
>>>>>>
>>>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne,
>>>>>> but
>>>>>> I
>>>>>> think we must choose one of:
>>>>>> 1- removing id-ne
>>>>>> 2- reintroducing validation
>>>>>>
>>>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>>>> wrote:
>>>>>>
>>>>>> Took a while to dig it out but here it is:
>>>>>>
>>>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>>>
>>>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>>>>
>>>>>>> the
>>>>>> same.
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 3 May 2017 at 17:42, Aditya Sharma <aditya.sharma@hotwaxsystems.c
>>>>>>> om>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Scott,
>>>>>>>
>>>>>>>> As there is very less information available with the commit I found
>>>>>>>> it
>>>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>>>
>>>>>>>> something.
>>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>>> Thanks & Regards,
>>>>>>>> Aditya Sharma
>>>>>>>> Enterprise Software Engineer
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>
>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>
>>>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>
>>>>>>>> Hi Taher,
>>>>>>>>
>>>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>>>
>>>>>>>>> default
>>>>>>> to
>>>>>>>
>>>>>>> false as that way it will not affect the current implementations and
>>>>>>>> will
>>>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>>>
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>> However!
>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>> database
>>>>>>>>> level (for not null), and also the default value should be false if
>>>>>>>>>
>>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>>>
>>>>>>>>>> validation
>>>>>>>>> attributes and how they apply.
>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>> Aditya Sharma
>>>>>>>>> Enterprise Software Engineer
>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>
>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>
>>>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>>>
>>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>> wrote:
>>>>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>>>>
>>>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>>>
>>>>>>>>>> deciding
>>>>>>>>> how to proceed.
>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>>
>>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>>> However!
>>>>>>>>> the
>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>>> database
>>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>>> if
>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>> validation
>>>>>>>>>> attributes and how they apply.
>>>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>>>
>>>>>>>>>>>> "*id*"
>>>>>>>>>> or "
>>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>>>> enriching
>>>>>>>>>>> discussion.
>>>>>>>>>>>
>>>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>>>
>>>>>>>>>>>> td2251546.html
>>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>>>
>>>>>>>>>>>> found
>>>>>>>>>> that
>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>>>> *java-type*
>>>>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>>>>
>>>>>>>>>>>> not-empty
>>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>>>>
>>>>>>>>>>>> field
>>>>>>>>>> type
>>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>>> level.
>>>>>>>>>> When dug into it further I can across this commit where validate
>>>>>>>> elements
>>>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>>
>>>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>>>
>>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>>>
>>>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>>>
>>>>>>>>>>>> whether
>>>>>>>>>> there
>>>>>>>> was some implementation that took its place for those
>>>>>>>>>>> validations.
>>>>>>>>>>>
>>>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>>> has
>>>>>>>>>> a
>>>>>>>> field
>>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>>> picklist*
>>>>>>>>>> for
>>>>>>>>> an
>>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>>> *empty*.
>>>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>>>
>>>>>>>>>>>> between
>>>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>>>> be a
>>>>>>>>>>>
>>>>>>>>>> Jira
>>>>>>>> for
>>>>>>>>>>> it.
>>>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>> and
>>>>>>>>> help me understanding it well.
>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>> Aditya Sharma
>>>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>>>
>>>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: Difference between "id" and "id-ne" field type
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
I have created the ticket for it OFBIZ-9351
<https://issues.apache.org/jira/browse/OFBIZ-9351>.
Jacques, Can you please elaborate some more on it.
When replacing id-ne alike fields by id alike we should add the "not-null"
> attribute.
For those fields where it requires not-empty fields values, we will be
implementing a new not-null attribute.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Mon, May 8, 2017 at 1:55 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Please Aditya create a Jira for that.
>
> Something I forgot to clearly mention. When replacing id-ne alike fields
> by id alike we should add the "not-null" attribute.
>
> Jacques
>
>
> Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
>
>> Thanks Scott for the link :)
>>
>> It completely makes sense to me now with what David said there.
>>
>> They are intentionally not used in other parts of the project as
>> validation
>>
>>> is
>>> best in the logic layer, and not in the data layer
>>>
>>> If those field types serve no purpose then it is better to remove them
>> to avoid any future confusions.
>>
>> Can I start working towards it then?
>>
>>
>> Thanks & Regards,
>> Aditya Sharma
>> Enterprise Software Engineer
>> HotWax Systems Pvt. Ltd.
>> http://www.hotwaxsystems.com/
>>
>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>
>>
>> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Thanks Guys for the links,
>>>
>>> I also agree we can now remove the useless id-ne, id-long-ne and
>>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>>> We also need to clean the related embedded documentation. Like for
>>> instance for "not-null" in fieldtypemodel.xsd
>>> For the rest let it be, I don't think there is much more documentation
>>> about that anyway.
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>>
>>> Chances are the field type was left for backwards compatibility. I'm ok
>>>> with it being removed though.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>>> wrote:
>>>>
>>>> Hmmm I was actually rethinking about this, and this reminds me somewhat
>>>> of
>>>>
>>>>> the "Bounded context" concept from DDD. Some services might want to
>>>>> validate while others don't on certain fields depending on context, and
>>>>> hence delegating that validation to services makes sense (no domain
>>>>> exists
>>>>> in OFBiz).
>>>>>
>>>>> The problem of the existence of id-ne lingers though. It's putting
>>>>> unneceasary cognitive strain on users to figure out what is it and what
>>>>> to
>>>>> do with it. Also, this means no validation can happen for entity-auto
>>>>> CRUD
>>>>> services.
>>>>>
>>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne,
>>>>> but
>>>>> I
>>>>> think we must choose one of:
>>>>> 1- removing id-ne
>>>>> 2- reintroducing validation
>>>>>
>>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>> Took a while to dig it out but here it is:
>>>>>
>>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>>
>>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>>>
>>>>>> the
>>>>>
>>>>> same.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 3 May 2017 at 17:42, Aditya Sharma <aditya.sharma@hotwaxsystems.c
>>>>>> om>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Scott,
>>>>>>
>>>>>>> As there is very less information available with the commit I found
>>>>>>> it
>>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>>
>>>>>>> something.
>>>>>>
>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Aditya Sharma
>>>>>>> Enterprise Software Engineer
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>
>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>
>>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>
>>>>>>> Hi Taher,
>>>>>>>
>>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>>
>>>>>>>> default
>>>>>>>
>>>>>> to
>>>>>>
>>>>>> false as that way it will not affect the current implementations and
>>>>>>> will
>>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>>
>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>> However!
>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>
>>>>>>>>> database
>>>>>>>> level (for not null), and also the default value should be false if
>>>>>>>>
>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>>
>>>>>>>>> validation
>>>>>>>> attributes and how they apply.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>> Aditya Sharma
>>>>>>>> Enterprise Software Engineer
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>
>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>
>>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>>
>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>>>
>>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>>
>>>>>>>>> deciding
>>>>>>>> how to proceed.
>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>>
>>>>>>>>>> However!
>>>>>>>>>
>>>>>>>> the
>>>>>>>
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>>
>>>>>>>>>> database
>>>>>>>>>
>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>>
>>>>>>>>>> if
>>>>>>>>>
>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>
>>>>>>> validation
>>>>>>>>>
>>>>>>>>> attributes and how they apply.
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>>
>>>>>>>>>>> "*id*"
>>>>>>>>>>
>>>>>>>>> or "
>>>>>>>
>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>>> enriching
>>>>>>>>>> discussion.
>>>>>>>>>>
>>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>>
>>>>>>>>>>> td2251546.html
>>>>>>>>>>
>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>>
>>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>>
>>>>>>>>>>> found
>>>>>>>>>>
>>>>>>>>> that
>>>>>>
>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>>
>>>>>>>>>>> *java-type*
>>>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>>>
>>>>>>>>>>> not-empty
>>>>>>>>>>
>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>>
>>>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>>>
>>>>>>>>>>> field
>>>>>>>>>>
>>>>>>>>> type
>>>>>>>>
>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>>
>>>>>>>>>>> level.
>>>>>>>>>>
>>>>>>>>> When dug into it further I can across this commit where validate
>>>>>>
>>>>>>> elements
>>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>>
>>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>>
>>>>>>>>>>> whether
>>>>>>>>>>
>>>>>>>>> there
>>>>>>
>>>>>>> was some implementation that took its place for those
>>>>>>>>>> validations.
>>>>>>>>>>
>>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>>
>>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>
>>>>>>> has
>>>>>>>>>>
>>>>>>>>> a
>>>>>>>
>>>>>>> field
>>>>>>>>
>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>>
>>>>>>>>>>> picklist*
>>>>>>>>>>
>>>>>>>>> for
>>>>>>>
>>>>>>>> an
>>>>>>>>>>
>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>>
>>>>>>>>>>> *empty*.
>>>>>>>>>>
>>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>>
>>>>>>>>>>> between
>>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>>> be a
>>>>>>>>>>
>>>>>>>>> Jira
>>>>>>
>>>>>>> for
>>>>>>>>>>
>>>>>>>>>> it.
>>>>>>>>>>>
>>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>> and
>>>>>>>
>>>>>>>> help me understanding it well.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Aditya Sharma
>>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>>
>>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>
Re: Difference between "id" and "id-ne" field type
Posted by Jacques Le Roux <ja...@les7arts.com>.
Please Aditya create a Jira for that.
Something I forgot to clearly mention. When replacing id-ne alike fields by id alike we should add the "not-null" attribute.
Jacques
Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
> Thanks Scott for the link :)
>
> It completely makes sense to me now with what David said there.
>
> They are intentionally not used in other parts of the project as validation
>> is
>> best in the logic layer, and not in the data layer
>>
> If those field types serve no purpose then it is better to remove them
> to avoid any future confusions.
>
> Can I start working towards it then?
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Thanks Guys for the links,
>>
>> I also agree we can now remove the useless id-ne, id-long-ne and
>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>> We also need to clean the related embedded documentation. Like for
>> instance for "not-null" in fieldtypemodel.xsd
>> For the rest let it be, I don't think there is much more documentation
>> about that anyway.
>>
>> Jacques
>>
>>
>>
>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>
>>> Chances are the field type was left for backwards compatibility. I'm ok
>>> with it being removed though.
>>>
>>> Regards
>>> Scott
>>>
>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>> wrote:
>>>
>>> Hmmm I was actually rethinking about this, and this reminds me somewhat of
>>>> the "Bounded context" concept from DDD. Some services might want to
>>>> validate while others don't on certain fields depending on context, and
>>>> hence delegating that validation to services makes sense (no domain
>>>> exists
>>>> in OFBiz).
>>>>
>>>> The problem of the existence of id-ne lingers though. It's putting
>>>> unneceasary cognitive strain on users to figure out what is it and what
>>>> to
>>>> do with it. Also, this means no validation can happen for entity-auto
>>>> CRUD
>>>> services.
>>>>
>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne, but
>>>> I
>>>> think we must choose one of:
>>>> 1- removing id-ne
>>>> 2- reintroducing validation
>>>>
>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>> Took a while to dig it out but here it is:
>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>
>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>>
>>>> the
>>>>
>>>>> same.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>> Hi Scott,
>>>>>> As there is very less information available with the commit I found it
>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>
>>>>> something.
>>>>>
>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Aditya Sharma
>>>>>> Enterprise Software Engineer
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> http://www.hotwaxsystems.com/
>>>>>>
>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>
>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>
>>>>>> default
>>>>> to
>>>>>
>>>>>> false as that way it will not affect the current implementations and
>>>>>> will
>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>> However!
>>>>>> the
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>
>>>>>>> database
>>>>>>> level (for not null), and also the default value should be false if
>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>
>>>>>>> validation
>>>>>>> attributes and how they apply.
>>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Aditya Sharma
>>>>>>> Enterprise Software Engineer
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>
>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>
>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>
>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>
>>>>>>> deciding
>>>>>>> how to proceed.
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>
>>>>>>>> However!
>>>>>> the
>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>
>>>>>>>> database
>>>>>>>>
>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>
>>>>>>>> if
>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>> validation
>>>>>>>>
>>>>>>>>> attributes and how they apply.
>>>>>>>>>
>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>
>>>>>>>>> "*id*"
>>>>>> or "
>>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>> enriching
>>>>>>>>> discussion.
>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>
>>>>>>>>> td2251546.html
>>>>>>>>>
>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>
>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>
>>>>>>>>> found
>>>>> that
>>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>> *java-type*
>>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>>
>>>>>>>>> not-empty
>>>>>>>>>
>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>
>>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>>
>>>>>>>>> field
>>>>>>> type
>>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>
>>>>>>>>> level.
>>>>> When dug into it further I can across this commit where validate
>>>>>>>>> elements
>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>
>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>
>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>
>>>>>>>>> whether
>>>>> there
>>>>>>>>> was some implementation that took its place for those
>>>>>>>>> validations.
>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>
>>>>>>>>> a
>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>>>> has
>>>>>> a
>>>>>>
>>>>>>> field
>>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>
>>>>>>>>> picklist*
>>>>>> for
>>>>>>>>> an
>>>>>>>>>
>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>
>>>>>>>>> *empty*.
>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>
>>>>>>>>> between
>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>> be a
>>>>> Jira
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>
>>>>>>>>> that
>>>>>> and
>>>>>>>>> help me understanding it well.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Aditya Sharma
>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>
>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>
>>>>>>>>>>
Re: Difference between "id" and "id-ne" field type
Posted by Taher Alkhateeb <sl...@gmail.com>.
+1
On Mon, May 8, 2017 at 10:52 AM, Deepak Dixit <
deepak.dixit@hotwaxsystems.com> wrote:
> +1
> make sense.
>
>
> Thanks Aditya,
> Feel free to open ticket for this change.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Mon, May 8, 2017 at 12:45 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > +1
> >
> > Jacques
> >
> >
> >
> > Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
> >
> >> Thanks Scott for the link :)
> >>
> >> It completely makes sense to me now with what David said there.
> >>
> >> They are intentionally not used in other parts of the project as
> >> validation
> >>
> >>> is
> >>> best in the logic layer, and not in the data layer
> >>>
> >>> If those field types serve no purpose then it is better to remove them
> >> to avoid any future confusions.
> >>
> >> Can I start working towards it then?
> >>
> >>
> >> Thanks & Regards,
> >> Aditya Sharma
> >> Enterprise Software Engineer
> >> HotWax Systems Pvt. Ltd.
> >> http://www.hotwaxsystems.com/
> >>
> >> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >>
> >> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
> >> jacques.le.roux@les7arts.com> wrote:
> >>
> >> Thanks Guys for the links,
> >>>
> >>> I also agree we can now remove the useless id-ne, id-long-ne and
> >>> id-vlong-ne field-types (ie replace by corresponding id field-types)
> >>> We also need to clean the related embedded documentation. Like for
> >>> instance for "not-null" in fieldtypemodel.xsd
> >>> For the rest let it be, I don't think there is much more documentation
> >>> about that anyway.
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
> >>>
> >>> Chances are the field type was left for backwards compatibility. I'm
> ok
> >>>> with it being removed though.
> >>>>
> >>>> Regards
> >>>> Scott
> >>>>
> >>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hmmm I was actually rethinking about this, and this reminds me
> somewhat
> >>>> of
> >>>>
> >>>>> the "Bounded context" concept from DDD. Some services might want to
> >>>>> validate while others don't on certain fields depending on context,
> and
> >>>>> hence delegating that validation to services makes sense (no domain
> >>>>> exists
> >>>>> in OFBiz).
> >>>>>
> >>>>> The problem of the existence of id-ne lingers though. It's putting
> >>>>> unneceasary cognitive strain on users to figure out what is it and
> what
> >>>>> to
> >>>>> do with it. Also, this means no validation can happen for entity-auto
> >>>>> CRUD
> >>>>> services.
> >>>>>
> >>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne,
> >>>>> but
> >>>>> I
> >>>>> think we must choose one of:
> >>>>> 1- removing id-ne
> >>>>> 2- reintroducing validation
> >>>>>
> >>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
> >>>>> wrote:
> >>>>>
> >>>>> Took a while to dig it out but here it is:
> >>>>>
> >>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
> >>>>>>
> >>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed
> all
> >>>>>>
> >>>>>> the
> >>>>>
> >>>>> same.
> >>>>>>
> >>>>>> Regards
> >>>>>> Scott
> >>>>>>
> >>>>>> On 3 May 2017 at 17:42, Aditya Sharma <aditya.sharma@hotwaxsystems.c
> >>>>>> om>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Scott,
> >>>>>>
> >>>>>>> As there is very less information available with the commit I found
> >>>>>>> it
> >>>>>>> quite difficult to find that discussion. Maybe I just missed out
> >>>>>>>
> >>>>>>> something.
> >>>>>>
> >>>>>> Could you please just help me trace that out to understand it well?
> >>>>>>>
> >>>>>>> Thanks & Regards,
> >>>>>>> Aditya Sharma
> >>>>>>> Enterprise Software Engineer
> >>>>>>> HotWax Systems Pvt. Ltd.
> >>>>>>> http://www.hotwaxsystems.com/
> >>>>>>>
> >>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >>>>>>>
> >>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
> >>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
> >>>>>>>
> >>>>>>> Hi Taher,
> >>>>>>>
> >>>>>>>> Totally agreed to that it should be at entity engine level and
> >>>>>>>>
> >>>>>>>> default
> >>>>>>>
> >>>>>> to
> >>>>>>
> >>>>>> false as that way it will not affect the current implementations and
> >>>>>>> will
> >>>>>>> give more scope for its enhancements to cater specific needs.
> >>>>>>>
> >>>>>>>> My recommendation is to reintroduce the validation attribute.
> >>>>>>>> However!
> >>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>> validation IMO should happen at the entity engine level, not the
> >>>>>>>>>
> >>>>>>>>> database
> >>>>>>>> level (for not null), and also the default value should be false
> if
> >>>>>>>>
> >>>>>>>>> omitted. We also need to think of the design in respect of the
> >>>>>>>>>
> >>>>>>>>> validation
> >>>>>>>> attributes and how they apply.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks & Regards,
> >>>>>>>> Aditya Sharma
> >>>>>>>> Enterprise Software Engineer
> >>>>>>>> HotWax Systems Pvt. Ltd.
> >>>>>>>> http://www.hotwaxsystems.com/
> >>>>>>>>
> >>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >>>>>>>>
> >>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
> >>>>>>>>
> >>>>>>>> scott.gray@hotwaxsystems.com>
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> It was removed purposefully and there was a discussion about it.
> I'd
> >>>>>>>>
> >>>>>>>>> suggest we all need to go back and look at that discussion before
> >>>>>>>>>
> >>>>>>>>> deciding
> >>>>>>>> how to proceed.
> >>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Scott
> >>>>>>>>>
> >>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <
> slidingfilaments@gmail.com>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>> I don't have the historical context, so please excuse if I'm off.
> >>>>>>>>
> >>>>>>>>> My recommendation is to reintroduce the validation attribute.
> >>>>>>>>>>
> >>>>>>>>>> However!
> >>>>>>>>>
> >>>>>>>> the
> >>>>>>>
> >>>>>>>> validation IMO should happen at the entity engine level, not the
> >>>>>>>>>>
> >>>>>>>>>> database
> >>>>>>>>>
> >>>>>>>>> level (for not null), and also the default value should be false
> >>>>>>>>>>
> >>>>>>>>>> if
> >>>>>>>>>
> >>>>>>>> omitted. We also need to think of the design in respect of the
> >>>>>>
> >>>>>>> validation
> >>>>>>>>>
> >>>>>>>>> attributes and how they apply.
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> >>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
> >>>>>>>>>>>
> >>>>>>>>>>> "*id*"
> >>>>>>>>>>
> >>>>>>>>> or "
> >>>>>>>
> >>>>>>>> *id-ne*" field type. When I googled it I came across this very
> >>>>>>>>>> enriching
> >>>>>>>>>> discussion.
> >>>>>>>>>>
> >>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> >>>>>>>>>>>
> >>>>>>>>>>> td2251546.html
> >>>>>>>>>>
> >>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
> >>>>>>>>>>>
> >>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
> >>>>>>>>>>>
> >>>>>>>>>>> found
> >>>>>>>>>>
> >>>>>>>>> that
> >>>>>>
> >>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
> >>>>>>>>>>
> >>>>>>>>>>> *java-type*
> >>>>>>>>>>> for these 2 field types but I couldn't get any trace of how
> that
> >>>>>>>>>>>
> >>>>>>>>>>> not-empty
> >>>>>>>>>>
> >>>>>>>>>> constraint is levied upon "id-ne" fields.
> >>>>>>>>>>>
> >>>>>>>>>>> I even looked at table structure for those fields having
> "id-ne"
> >>>>>>>>>>>
> >>>>>>>>>>> field
> >>>>>>>>>>
> >>>>>>>>> type
> >>>>>>>>
> >>>>>>>>> but there was no "not-null" constraint at even the database
> >>>>>>>>>>>
> >>>>>>>>>>> level.
> >>>>>>>>>>
> >>>>>>>>> When dug into it further I can across this commit where validate
> >>>>>>
> >>>>>>> elements
> >>>>>>>>>> were removed from fieldtype*.xml files.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
> >>>>>>>>>>>
> >>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
> >>>>>>>>>>>
> >>>>>>>>>>> But I can't get why it was removed and when it was removed
> >>>>>>>>>>>
> >>>>>>>>>>> whether
> >>>>>>>>>>
> >>>>>>>>> there
> >>>>>>
> >>>>>>> was some implementation that took its place for those
> >>>>>>>>>> validations.
> >>>>>>>>>>
> >>>>>>>>>>> To further check if it even works I found an OOTB entity having
> >>>>>>>>>>>
> >>>>>>>>>>> a
> >>>>>>>>>>
> >>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
> >>>>>>
> >>>>>>> has
> >>>>>>>>>>
> >>>>>>>>> a
> >>>>>>>
> >>>>>>> field
> >>>>>>>>
> >>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
> >>>>>>>>>>>
> >>>>>>>>>>> picklist*
> >>>>>>>>>>
> >>>>>>>>> for
> >>>>>>>
> >>>>>>>> an
> >>>>>>>>>>
> >>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
> >>>>>>>>>>>
> >>>>>>>>>>> *empty*.
> >>>>>>>>>>
> >>>>>>>>>>> If my explorations are correct currently there is no difference
> >>>>>>>>>>>
> >>>>>>>>>>> between
> >>>>>>>>>> "id" and "id-ne" at the implementation level and there should
> >>>>>>>>>> be a
> >>>>>>>>>>
> >>>>>>>>> Jira
> >>>>>>
> >>>>>>> for
> >>>>>>>>>>
> >>>>>>>>>> it.
> >>>>>>>>>>>
> >>>>>>>>>>> If I missed out something, can someone please enlighten me with
> >>>>>>>>>>>
> >>>>>>>>>>> that
> >>>>>>>>>>
> >>>>>>>>> and
> >>>>>>>
> >>>>>>>> help me understanding it well.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks & Regards,
> >>>>>>>>>>> Aditya Sharma
> >>>>>>>>>>> Enterprise Software Engineer
> >>>>>>>>>>> HotWax Systems Pvt. Ltd.
> >>>>>>>>>>> http://www.hotwaxsystems.com/
> >>>>>>>>>>>
> >>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >
>
Re: Difference between "id" and "id-ne" field type
Posted by Deepak Dixit <de...@hotwaxsystems.com>.
+1
make sense.
Thanks Aditya,
Feel free to open ticket for this change.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Mon, May 8, 2017 at 12:45 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> +1
>
> Jacques
>
>
>
> Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
>
>> Thanks Scott for the link :)
>>
>> It completely makes sense to me now with what David said there.
>>
>> They are intentionally not used in other parts of the project as
>> validation
>>
>>> is
>>> best in the logic layer, and not in the data layer
>>>
>>> If those field types serve no purpose then it is better to remove them
>> to avoid any future confusions.
>>
>> Can I start working towards it then?
>>
>>
>> Thanks & Regards,
>> Aditya Sharma
>> Enterprise Software Engineer
>> HotWax Systems Pvt. Ltd.
>> http://www.hotwaxsystems.com/
>>
>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>
>> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Thanks Guys for the links,
>>>
>>> I also agree we can now remove the useless id-ne, id-long-ne and
>>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>>> We also need to clean the related embedded documentation. Like for
>>> instance for "not-null" in fieldtypemodel.xsd
>>> For the rest let it be, I don't think there is much more documentation
>>> about that anyway.
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>>
>>> Chances are the field type was left for backwards compatibility. I'm ok
>>>> with it being removed though.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>>> wrote:
>>>>
>>>> Hmmm I was actually rethinking about this, and this reminds me somewhat
>>>> of
>>>>
>>>>> the "Bounded context" concept from DDD. Some services might want to
>>>>> validate while others don't on certain fields depending on context, and
>>>>> hence delegating that validation to services makes sense (no domain
>>>>> exists
>>>>> in OFBiz).
>>>>>
>>>>> The problem of the existence of id-ne lingers though. It's putting
>>>>> unneceasary cognitive strain on users to figure out what is it and what
>>>>> to
>>>>> do with it. Also, this means no validation can happen for entity-auto
>>>>> CRUD
>>>>> services.
>>>>>
>>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne,
>>>>> but
>>>>> I
>>>>> think we must choose one of:
>>>>> 1- removing id-ne
>>>>> 2- reintroducing validation
>>>>>
>>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>> Took a while to dig it out but here it is:
>>>>>
>>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>>
>>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>>>
>>>>>> the
>>>>>
>>>>> same.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 3 May 2017 at 17:42, Aditya Sharma <aditya.sharma@hotwaxsystems.c
>>>>>> om>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Scott,
>>>>>>
>>>>>>> As there is very less information available with the commit I found
>>>>>>> it
>>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>>
>>>>>>> something.
>>>>>>
>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Aditya Sharma
>>>>>>> Enterprise Software Engineer
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>
>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>
>>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>
>>>>>>> Hi Taher,
>>>>>>>
>>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>>
>>>>>>>> default
>>>>>>>
>>>>>> to
>>>>>>
>>>>>> false as that way it will not affect the current implementations and
>>>>>>> will
>>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>>
>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>> However!
>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>
>>>>>>>>> database
>>>>>>>> level (for not null), and also the default value should be false if
>>>>>>>>
>>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>>
>>>>>>>>> validation
>>>>>>>> attributes and how they apply.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>> Aditya Sharma
>>>>>>>> Enterprise Software Engineer
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>
>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>
>>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>>
>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>>>
>>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>>
>>>>>>>>> deciding
>>>>>>>> how to proceed.
>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>>
>>>>>>>>>> However!
>>>>>>>>>
>>>>>>>> the
>>>>>>>
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>>
>>>>>>>>>> database
>>>>>>>>>
>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>>
>>>>>>>>>> if
>>>>>>>>>
>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>
>>>>>>> validation
>>>>>>>>>
>>>>>>>>> attributes and how they apply.
>>>>>>>>>>
>>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>>
>>>>>>>>>>> "*id*"
>>>>>>>>>>
>>>>>>>>> or "
>>>>>>>
>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>>> enriching
>>>>>>>>>> discussion.
>>>>>>>>>>
>>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>>
>>>>>>>>>>> td2251546.html
>>>>>>>>>>
>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>>
>>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>>
>>>>>>>>>>> found
>>>>>>>>>>
>>>>>>>>> that
>>>>>>
>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>>
>>>>>>>>>>> *java-type*
>>>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>>>
>>>>>>>>>>> not-empty
>>>>>>>>>>
>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>>
>>>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>>>
>>>>>>>>>>> field
>>>>>>>>>>
>>>>>>>>> type
>>>>>>>>
>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>>
>>>>>>>>>>> level.
>>>>>>>>>>
>>>>>>>>> When dug into it further I can across this commit where validate
>>>>>>
>>>>>>> elements
>>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>>
>>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>>
>>>>>>>>>>> whether
>>>>>>>>>>
>>>>>>>>> there
>>>>>>
>>>>>>> was some implementation that took its place for those
>>>>>>>>>> validations.
>>>>>>>>>>
>>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>>
>>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>
>>>>>>> has
>>>>>>>>>>
>>>>>>>>> a
>>>>>>>
>>>>>>> field
>>>>>>>>
>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>>
>>>>>>>>>>> picklist*
>>>>>>>>>>
>>>>>>>>> for
>>>>>>>
>>>>>>>> an
>>>>>>>>>>
>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>>
>>>>>>>>>>> *empty*.
>>>>>>>>>>
>>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>>
>>>>>>>>>>> between
>>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>>> be a
>>>>>>>>>>
>>>>>>>>> Jira
>>>>>>
>>>>>>> for
>>>>>>>>>>
>>>>>>>>>> it.
>>>>>>>>>>>
>>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>> and
>>>>>>>
>>>>>>>> help me understanding it well.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Aditya Sharma
>>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>>
>>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>
Re: Difference between "id" and "id-ne" field type
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1
Jacques
Le 08/05/2017 à 08:32, Aditya Sharma a écrit :
> Thanks Scott for the link :)
>
> It completely makes sense to me now with what David said there.
>
> They are intentionally not used in other parts of the project as validation
>> is
>> best in the logic layer, and not in the data layer
>>
> If those field types serve no purpose then it is better to remove them
> to avoid any future confusions.
>
> Can I start working towards it then?
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Thanks Guys for the links,
>>
>> I also agree we can now remove the useless id-ne, id-long-ne and
>> id-vlong-ne field-types (ie replace by corresponding id field-types)
>> We also need to clean the related embedded documentation. Like for
>> instance for "not-null" in fieldtypemodel.xsd
>> For the rest let it be, I don't think there is much more documentation
>> about that anyway.
>>
>> Jacques
>>
>>
>>
>> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>>
>>> Chances are the field type was left for backwards compatibility. I'm ok
>>> with it being removed though.
>>>
>>> Regards
>>> Scott
>>>
>>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>>> wrote:
>>>
>>> Hmmm I was actually rethinking about this, and this reminds me somewhat of
>>>> the "Bounded context" concept from DDD. Some services might want to
>>>> validate while others don't on certain fields depending on context, and
>>>> hence delegating that validation to services makes sense (no domain
>>>> exists
>>>> in OFBiz).
>>>>
>>>> The problem of the existence of id-ne lingers though. It's putting
>>>> unneceasary cognitive strain on users to figure out what is it and what
>>>> to
>>>> do with it. Also, this means no validation can happen for entity-auto
>>>> CRUD
>>>> services.
>>>>
>>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne, but
>>>> I
>>>> think we must choose one of:
>>>> 1- removing id-ne
>>>> 2- reintroducing validation
>>>>
>>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>> Took a while to dig it out but here it is:
>>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>>
>>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>>
>>>> the
>>>>
>>>>> same.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>> Hi Scott,
>>>>>> As there is very less information available with the commit I found it
>>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>>
>>>>> something.
>>>>>
>>>>>> Could you please just help me trace that out to understand it well?
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Aditya Sharma
>>>>>> Enterprise Software Engineer
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> http://www.hotwaxsystems.com/
>>>>>>
>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>
>>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>>
>>>>>> default
>>>>> to
>>>>>
>>>>>> false as that way it will not affect the current implementations and
>>>>>> will
>>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>> However!
>>>>>> the
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>
>>>>>>> database
>>>>>>> level (for not null), and also the default value should be false if
>>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>
>>>>>>> validation
>>>>>>> attributes and how they apply.
>>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Aditya Sharma
>>>>>>> Enterprise Software Engineer
>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>
>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>
>>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>>
>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>>
>>>>>>> deciding
>>>>>>> how to proceed.
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>>
>>>>>>>> However!
>>>>>> the
>>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>>
>>>>>>>> database
>>>>>>>>
>>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>>
>>>>>>>> if
>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>> validation
>>>>>>>>
>>>>>>>>> attributes and how they apply.
>>>>>>>>>
>>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>>
>>>>>>>>> "*id*"
>>>>>> or "
>>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>> enriching
>>>>>>>>> discussion.
>>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>>
>>>>>>>>> td2251546.html
>>>>>>>>>
>>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>>
>>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>>
>>>>>>>>> found
>>>>> that
>>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>>> *java-type*
>>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>>
>>>>>>>>> not-empty
>>>>>>>>>
>>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>>
>>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>>
>>>>>>>>> field
>>>>>>> type
>>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>>
>>>>>>>>> level.
>>>>> When dug into it further I can across this commit where validate
>>>>>>>>> elements
>>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>>
>>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>>
>>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>>
>>>>>>>>> whether
>>>>> there
>>>>>>>>> was some implementation that took its place for those
>>>>>>>>> validations.
>>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>>
>>>>>>>>> a
>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>>>> has
>>>>>> a
>>>>>>
>>>>>>> field
>>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>>
>>>>>>>>> picklist*
>>>>>> for
>>>>>>>>> an
>>>>>>>>>
>>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>>
>>>>>>>>> *empty*.
>>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>>
>>>>>>>>> between
>>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>> be a
>>>>> Jira
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>>
>>>>>>>>> that
>>>>>> and
>>>>>>>>> help me understanding it well.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Aditya Sharma
>>>>>>>>>> Enterprise Software Engineer
>>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>>
>>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>>
>>>>>>>>>>
Re: Difference between "id" and "id-ne" field type
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
Thanks Scott for the link :)
It completely makes sense to me now with what David said there.
They are intentionally not used in other parts of the project as validation
> is
> best in the logic layer, and not in the data layer
>
If those field types serve no purpose then it is better to remove them
to avoid any future confusions.
Can I start working towards it then?
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Sat, May 6, 2017 at 7:45 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Thanks Guys for the links,
>
> I also agree we can now remove the useless id-ne, id-long-ne and
> id-vlong-ne field-types (ie replace by corresponding id field-types)
> We also need to clean the related embedded documentation. Like for
> instance for "not-null" in fieldtypemodel.xsd
> For the rest let it be, I don't think there is much more documentation
> about that anyway.
>
> Jacques
>
>
>
> Le 04/05/2017 à 06:20, Scott Gray a écrit :
>
>> Chances are the field type was left for backwards compatibility. I'm ok
>> with it being removed though.
>>
>> Regards
>> Scott
>>
>> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com>
>> wrote:
>>
>> Hmmm I was actually rethinking about this, and this reminds me somewhat of
>>> the "Bounded context" concept from DDD. Some services might want to
>>> validate while others don't on certain fields depending on context, and
>>> hence delegating that validation to services makes sense (no domain
>>> exists
>>> in OFBiz).
>>>
>>> The problem of the existence of id-ne lingers though. It's putting
>>> unneceasary cognitive strain on users to figure out what is it and what
>>> to
>>> do with it. Also, this means no validation can happen for entity-auto
>>> CRUD
>>> services.
>>>
>>> So, I'm a bit on the fence, leaning slightly towards removing id-ne, but
>>> I
>>> think we must choose one of:
>>> 1- removing id-ne
>>> 2- reintroducing validation
>>>
>>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com>
>>> wrote:
>>>
>>> Took a while to dig it out but here it is:
>>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>>
>>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>>>>
>>> the
>>>
>>>> same.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>> Hi Scott,
>>>>>
>>>>> As there is very less information available with the commit I found it
>>>>> quite difficult to find that discussion. Maybe I just missed out
>>>>>
>>>> something.
>>>>
>>>>> Could you please just help me trace that out to understand it well?
>>>>>
>>>>> Thanks & Regards,
>>>>> Aditya Sharma
>>>>> Enterprise Software Engineer
>>>>> HotWax Systems Pvt. Ltd.
>>>>> http://www.hotwaxsystems.com/
>>>>>
>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>
>>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>
>>>>> Hi Taher,
>>>>>>
>>>>>> Totally agreed to that it should be at entity engine level and
>>>>>>
>>>>> default
>>>
>>>> to
>>>>
>>>>> false as that way it will not affect the current implementations and
>>>>>>
>>>>> will
>>>>
>>>>> give more scope for its enhancements to cater specific needs.
>>>>>>
>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>
>>>>>> However!
>>>>
>>>>> the
>>>>>>
>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>
>>>>>> database
>>>>>
>>>>>> level (for not null), and also the default value should be false if
>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>>>
>>>>>> validation
>>>>>
>>>>>> attributes and how they apply.
>>>>>>>
>>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Aditya Sharma
>>>>>> Enterprise Software Engineer
>>>>>> HotWax Systems Pvt. Ltd.
>>>>>> http://www.hotwaxsystems.com/
>>>>>>
>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>
>>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>>>>
>>>>> scott.gray@hotwaxsystems.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>>> suggest we all need to go back and look at that discussion before
>>>>>>>
>>>>>> deciding
>>>>>
>>>>>> how to proceed.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>>
>>>>>>>> My recommendation is to reintroduce the validation attribute.
>>>>>>>>
>>>>>>> However!
>>>>
>>>>> the
>>>>>>>
>>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>>>>
>>>>>>> database
>>>>>>>
>>>>>>>> level (for not null), and also the default value should be false
>>>>>>>>
>>>>>>> if
>>>
>>>> omitted. We also need to think of the design in respect of the
>>>>>>>>
>>>>>>> validation
>>>>>>>
>>>>>>>> attributes and how they apply.
>>>>>>>>
>>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>>>>>>>>
>>>>>>>> "*id*"
>>>>
>>>>> or "
>>>>>>>
>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>>>>>
>>>>>>>> enriching
>>>>>>>
>>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>>>>
>>>>>>>> td2251546.html
>>>>>>>>
>>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>>
>>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>>>>>>>>>
>>>>>>>> found
>>>
>>>> that
>>>>>>>
>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>>> *java-type*
>>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>>>>
>>>>>>>> not-empty
>>>>>>>>
>>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>>
>>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>>>>>>>
>>>>>>>> field
>>>>>
>>>>>> type
>>>>>>>>
>>>>>>>>> but there was no "not-null" constraint at even the database
>>>>>>>>>
>>>>>>>> level.
>>>
>>>> When dug into it further I can across this commit where validate
>>>>>>>>>
>>>>>>>> elements
>>>>>>>
>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>>
>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>>
>>>>>>>>> But I can't get why it was removed and when it was removed
>>>>>>>>>
>>>>>>>> whether
>>>
>>>> there
>>>>>>>
>>>>>>>> was some implementation that took its place for those
>>>>>>>>>
>>>>>>>> validations.
>>>
>>>>
>>>>>>>>> To further check if it even works I found an OOTB entity having
>>>>>>>>>
>>>>>>>> a
>>>
>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>>>>>>>>
>>>>>>>> has
>>>>
>>>>> a
>>>>>
>>>>>> field
>>>>>>>>
>>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>>>>>>>>
>>>>>>>> picklist*
>>>>
>>>>> for
>>>>>>>
>>>>>>>> an
>>>>>>>>
>>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>>>>>>>>
>>>>>>>> *empty*.
>>>>
>>>>>
>>>>>>>>> If my explorations are correct currently there is no difference
>>>>>>>>>
>>>>>>>> between
>>>>>>>
>>>>>>>> "id" and "id-ne" at the implementation level and there should
>>>>>>>>>
>>>>>>>> be a
>>>
>>>> Jira
>>>>>>>
>>>>>>>> for
>>>>>>>>
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> If I missed out something, can someone please enlighten me with
>>>>>>>>>
>>>>>>>> that
>>>>
>>>>> and
>>>>>>>
>>>>>>>> help me understanding it well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Aditya Sharma
>>>>>>>>> Enterprise Software Engineer
>>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>>
>>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>
Re: Difference between "id" and "id-ne" field type
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Guys for the links,
I also agree we can now remove the useless id-ne, id-long-ne and id-vlong-ne field-types (ie replace by corresponding id field-types)
We also need to clean the related embedded documentation. Like for instance for "not-null" in fieldtypemodel.xsd
For the rest let it be, I don't think there is much more documentation about that anyway.
Jacques
Le 04/05/2017 à 06:20, Scott Gray a écrit :
> Chances are the field type was left for backwards compatibility. I'm ok
> with it being removed though.
>
> Regards
> Scott
>
> On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com> wrote:
>
>> Hmmm I was actually rethinking about this, and this reminds me somewhat of
>> the "Bounded context" concept from DDD. Some services might want to
>> validate while others don't on certain fields depending on context, and
>> hence delegating that validation to services makes sense (no domain exists
>> in OFBiz).
>>
>> The problem of the existence of id-ne lingers though. It's putting
>> unneceasary cognitive strain on users to figure out what is it and what to
>> do with it. Also, this means no validation can happen for entity-auto CRUD
>> services.
>>
>> So, I'm a bit on the fence, leaning slightly towards removing id-ne, but I
>> think we must choose one of:
>> 1- removing id-ne
>> 2- reintroducing validation
>>
>> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com> wrote:
>>
>>> Took a while to dig it out but here it is:
>>> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>>>
>>> It's not as in-depth as I'd hoped, but it was purposefully removed all
>> the
>>> same.
>>>
>>> Regards
>>> Scott
>>>
>>> On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
>>> wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> As there is very less information available with the commit I found it
>>>> quite difficult to find that discussion. Maybe I just missed out
>>> something.
>>>> Could you please just help me trace that out to understand it well?
>>>>
>>>> Thanks & Regards,
>>>> Aditya Sharma
>>>> Enterprise Software Engineer
>>>> HotWax Systems Pvt. Ltd.
>>>> http://www.hotwaxsystems.com/
>>>>
>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>
>>>> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>
>>>>> Hi Taher,
>>>>>
>>>>> Totally agreed to that it should be at entity engine level and
>> default
>>> to
>>>>> false as that way it will not affect the current implementations and
>>> will
>>>>> give more scope for its enhancements to cater specific needs.
>>>>>
>>>>>> My recommendation is to reintroduce the validation attribute.
>>> However!
>>>>> the
>>>>>> validation IMO should happen at the entity engine level, not the
>>>> database
>>>>>> level (for not null), and also the default value should be false if
>>>>>> omitted. We also need to think of the design in respect of the
>>>> validation
>>>>>> attributes and how they apply.
>>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Aditya Sharma
>>>>> Enterprise Software Engineer
>>>>> HotWax Systems Pvt. Ltd.
>>>>> http://www.hotwaxsystems.com/
>>>>>
>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>
>>>>> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
>>>> scott.gray@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>>> It was removed purposefully and there was a discussion about it. I'd
>>>>>> suggest we all need to go back and look at that discussion before
>>>> deciding
>>>>>> how to proceed.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
>>>> wrote:
>>>>>>> I don't have the historical context, so please excuse if I'm off.
>>>>>>>
>>>>>>> My recommendation is to reintroduce the validation attribute.
>>> However!
>>>>>> the
>>>>>>> validation IMO should happen at the entity engine level, not the
>>>>>> database
>>>>>>> level (for not null), and also the default value should be false
>> if
>>>>>>> omitted. We also need to think of the design in respect of the
>>>>>> validation
>>>>>>> attributes and how they apply.
>>>>>>>
>>>>>>> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>>>>>>> aditya.sharma@hotwaxsystems.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> While creating an entity I was in ambiguity whether to go for
>>> "*id*"
>>>>>> or "
>>>>>>>> *id-ne*" field type. When I googled it I came across this very
>>>>>> enriching
>>>>>>>> discussion.
>>>>>>>>
>>>>>>>> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>>>>>>> td2251546.html
>>>>>>>> As stated, an "id-ne" field can only have a *non-empty* value.
>>>>>>>>
>>>>>>>> I was very curious to know how it is implemented in OFBiz. I
>> found
>>>>>> that
>>>>>>>> almost all the *fieldtype*.xml* files have *same* *sql-type* and
>>>>>>>> *java-type*
>>>>>>>> for these 2 field types but I couldn't get any trace of how that
>>>>>>> not-empty
>>>>>>>> constraint is levied upon "id-ne" fields.
>>>>>>>>
>>>>>>>> I even looked at table structure for those fields having "id-ne"
>>>> field
>>>>>>> type
>>>>>>>> but there was no "not-null" constraint at even the database
>> level.
>>>>>>>> When dug into it further I can across this commit where validate
>>>>>> elements
>>>>>>>> were removed from fieldtype*.xml files.
>>>>>>>>
>>>>>>>>
>>>>>>>> http://markmail.org/message/otec62xiwkpjttkq
>>>>>>>>
>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=959708
>>>>>>>>
>>>>>>>> But I can't get why it was removed and when it was removed
>> whether
>>>>>> there
>>>>>>>> was some implementation that took its place for those
>> validations.
>>>>>>>>
>>>>>>>> To further check if it even works I found an OOTB entity having
>> a
>>>>>>>> non-primary key "id-ne" field. I found that "*Picklist*" entity
>>> has
>>>> a
>>>>>>> field
>>>>>>>> *shipmentMethodTypeId* as "id- ne" type. When we *create a
>>> picklist*
>>>>>> for
>>>>>>> an
>>>>>>>> order from Facility Manager, *shipmentMethodTypeId* can be
>>> *empty*.
>>>>>>>>
>>>>>>>> If my explorations are correct currently there is no difference
>>>>>> between
>>>>>>>> "id" and "id-ne" at the implementation level and there should
>> be a
>>>>>> Jira
>>>>>>> for
>>>>>>>> it.
>>>>>>>>
>>>>>>>> If I missed out something, can someone please enlighten me with
>>> that
>>>>>> and
>>>>>>>> help me understanding it well.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks & Regards,
>>>>>>>> Aditya Sharma
>>>>>>>> Enterprise Software Engineer
>>>>>>>> HotWax Systems Pvt. Ltd.
>>>>>>>> http://www.hotwaxsystems.com/
>>>>>>>>
>>>>>>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>>>>>>>
>>>>>
Re: Difference between "id" and "id-ne" field type
Posted by Scott Gray <sc...@hotwaxsystems.com>.
Chances are the field type was left for backwards compatibility. I'm ok
with it being removed though.
Regards
Scott
On 4 May 2017 at 15:32, Taher Alkhateeb <sl...@gmail.com> wrote:
> Hmmm I was actually rethinking about this, and this reminds me somewhat of
> the "Bounded context" concept from DDD. Some services might want to
> validate while others don't on certain fields depending on context, and
> hence delegating that validation to services makes sense (no domain exists
> in OFBiz).
>
> The problem of the existence of id-ne lingers though. It's putting
> unneceasary cognitive strain on users to figure out what is it and what to
> do with it. Also, this means no validation can happen for entity-auto CRUD
> services.
>
> So, I'm a bit on the fence, leaning slightly towards removing id-ne, but I
> think we must choose one of:
> 1- removing id-ne
> 2- reintroducing validation
>
> On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com> wrote:
>
> > Took a while to dig it out but here it is:
> > http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
> >
> > It's not as in-depth as I'd hoped, but it was purposefully removed all
> the
> > same.
> >
> > Regards
> > Scott
> >
> > On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
> > wrote:
> >
> > > Hi Scott,
> > >
> > > As there is very less information available with the commit I found it
> > > quite difficult to find that discussion. Maybe I just missed out
> > something.
> > > Could you please just help me trace that out to understand it well?
> > >
> > > Thanks & Regards,
> > > Aditya Sharma
> > > Enterprise Software Engineer
> > > HotWax Systems Pvt. Ltd.
> > > http://www.hotwaxsystems.com/
> > >
> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > >
> > > On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
> > > aditya.sharma@hotwaxsystems.com> wrote:
> > >
> > > > Hi Taher,
> > > >
> > > > Totally agreed to that it should be at entity engine level and
> default
> > to
> > > > false as that way it will not affect the current implementations and
> > will
> > > > give more scope for its enhancements to cater specific needs.
> > > >
> > > > > My recommendation is to reintroduce the validation attribute.
> > However!
> > > > the
> > > > > validation IMO should happen at the entity engine level, not the
> > > database
> > > > > level (for not null), and also the default value should be false if
> > > > > omitted. We also need to think of the design in respect of the
> > > validation
> > > > > attributes and how they apply.
> > > > >
> > > >
> > > >
> > > > Thanks & Regards,
> > > > Aditya Sharma
> > > > Enterprise Software Engineer
> > > > HotWax Systems Pvt. Ltd.
> > > > http://www.hotwaxsystems.com/
> > > >
> > > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > > >
> > > > On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
> > > scott.gray@hotwaxsystems.com>
> > > > wrote:
> > > >
> > > >> It was removed purposefully and there was a discussion about it. I'd
> > > >> suggest we all need to go back and look at that discussion before
> > > deciding
> > > >> how to proceed.
> > > >>
> > > >> Regards
> > > >> Scott
> > > >>
> > > >> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
> > > wrote:
> > > >>
> > > >> > I don't have the historical context, so please excuse if I'm off.
> > > >> >
> > > >> > My recommendation is to reintroduce the validation attribute.
> > However!
> > > >> the
> > > >> > validation IMO should happen at the entity engine level, not the
> > > >> database
> > > >> > level (for not null), and also the default value should be false
> if
> > > >> > omitted. We also need to think of the design in respect of the
> > > >> validation
> > > >> > attributes and how they apply.
> > > >> >
> > > >> > On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> > > >> > aditya.sharma@hotwaxsystems.com> wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > While creating an entity I was in ambiguity whether to go for
> > "*id*"
> > > >> or "
> > > >> > > *id-ne*" field type. When I googled it I came across this very
> > > >> enriching
> > > >> > > discussion.
> > > >> > >
> > > >> > > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> > > >> > td2251546.html
> > > >> > >
> > > >> > > As stated, an "id-ne" field can only have a *non-empty* value.
> > > >> > >
> > > >> > > I was very curious to know how it is implemented in OFBiz. I
> found
> > > >> that
> > > >> > > almost all the *fieldtype*.xml* files have *same* *sql-type* and
> > > >> > > *java-type*
> > > >> > > for these 2 field types but I couldn't get any trace of how that
> > > >> > not-empty
> > > >> > > constraint is levied upon "id-ne" fields.
> > > >> > >
> > > >> > > I even looked at table structure for those fields having "id-ne"
> > > field
> > > >> > type
> > > >> > > but there was no "not-null" constraint at even the database
> level.
> > > >> > >
> > > >> > > When dug into it further I can across this commit where validate
> > > >> elements
> > > >> > > were removed from fieldtype*.xml files.
> > > >> > >
> > > >> > >
> > > >> > > http://markmail.org/message/otec62xiwkpjttkq
> > > >> > >
> > > >> > > http://svn.apache.org/viewvc?view=revision&revision=959708
> > > >> > >
> > > >> > > But I can't get why it was removed and when it was removed
> whether
> > > >> there
> > > >> > > was some implementation that took its place for those
> validations.
> > > >> > >
> > > >> > >
> > > >> > > To further check if it even works I found an OOTB entity having
> a
> > > >> > > non-primary key "id-ne" field. I found that "*Picklist*" entity
> > has
> > > a
> > > >> > field
> > > >> > > *shipmentMethodTypeId* as "id- ne" type. When we *create a
> > picklist*
> > > >> for
> > > >> > an
> > > >> > > order from Facility Manager, *shipmentMethodTypeId* can be
> > *empty*.
> > > >> > >
> > > >> > >
> > > >> > > If my explorations are correct currently there is no difference
> > > >> between
> > > >> > > "id" and "id-ne" at the implementation level and there should
> be a
> > > >> Jira
> > > >> > for
> > > >> > > it.
> > > >> > >
> > > >> > > If I missed out something, can someone please enlighten me with
> > that
> > > >> and
> > > >> > > help me understanding it well.
> > > >> > >
> > > >> > >
> > > >> > > Thanks & Regards,
> > > >> > > Aditya Sharma
> > > >> > > Enterprise Software Engineer
> > > >> > > HotWax Systems Pvt. Ltd.
> > > >> > > http://www.hotwaxsystems.com/
> > > >> > >
> > > >> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Difference between "id" and "id-ne" field type
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hmmm I was actually rethinking about this, and this reminds me somewhat of
the "Bounded context" concept from DDD. Some services might want to
validate while others don't on certain fields depending on context, and
hence delegating that validation to services makes sense (no domain exists
in OFBiz).
The problem of the existence of id-ne lingers though. It's putting
unneceasary cognitive strain on users to figure out what is it and what to
do with it. Also, this means no validation can happen for entity-auto CRUD
services.
So, I'm a bit on the fence, leaning slightly towards removing id-ne, but I
think we must choose one of:
1- removing id-ne
2- reintroducing validation
On May 4, 2017 3:10 AM, "Scott Gray" <sc...@hotwaxsystems.com> wrote:
> Took a while to dig it out but here it is:
> http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
>
> It's not as in-depth as I'd hoped, but it was purposefully removed all the
> same.
>
> Regards
> Scott
>
> On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
> wrote:
>
> > Hi Scott,
> >
> > As there is very less information available with the commit I found it
> > quite difficult to find that discussion. Maybe I just missed out
> something.
> > Could you please just help me trace that out to understand it well?
> >
> > Thanks & Regards,
> > Aditya Sharma
> > Enterprise Software Engineer
> > HotWax Systems Pvt. Ltd.
> > http://www.hotwaxsystems.com/
> >
> > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >
> > On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
> > aditya.sharma@hotwaxsystems.com> wrote:
> >
> > > Hi Taher,
> > >
> > > Totally agreed to that it should be at entity engine level and default
> to
> > > false as that way it will not affect the current implementations and
> will
> > > give more scope for its enhancements to cater specific needs.
> > >
> > > > My recommendation is to reintroduce the validation attribute.
> However!
> > > the
> > > > validation IMO should happen at the entity engine level, not the
> > database
> > > > level (for not null), and also the default value should be false if
> > > > omitted. We also need to think of the design in respect of the
> > validation
> > > > attributes and how they apply.
> > > >
> > >
> > >
> > > Thanks & Regards,
> > > Aditya Sharma
> > > Enterprise Software Engineer
> > > HotWax Systems Pvt. Ltd.
> > > http://www.hotwaxsystems.com/
> > >
> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > >
> > > On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
> > scott.gray@hotwaxsystems.com>
> > > wrote:
> > >
> > >> It was removed purposefully and there was a discussion about it. I'd
> > >> suggest we all need to go back and look at that discussion before
> > deciding
> > >> how to proceed.
> > >>
> > >> Regards
> > >> Scott
> > >>
> > >> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
> > wrote:
> > >>
> > >> > I don't have the historical context, so please excuse if I'm off.
> > >> >
> > >> > My recommendation is to reintroduce the validation attribute.
> However!
> > >> the
> > >> > validation IMO should happen at the entity engine level, not the
> > >> database
> > >> > level (for not null), and also the default value should be false if
> > >> > omitted. We also need to think of the design in respect of the
> > >> validation
> > >> > attributes and how they apply.
> > >> >
> > >> > On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> > >> > aditya.sharma@hotwaxsystems.com> wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > While creating an entity I was in ambiguity whether to go for
> "*id*"
> > >> or "
> > >> > > *id-ne*" field type. When I googled it I came across this very
> > >> enriching
> > >> > > discussion.
> > >> > >
> > >> > > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> > >> > td2251546.html
> > >> > >
> > >> > > As stated, an "id-ne" field can only have a *non-empty* value.
> > >> > >
> > >> > > I was very curious to know how it is implemented in OFBiz. I found
> > >> that
> > >> > > almost all the *fieldtype*.xml* files have *same* *sql-type* and
> > >> > > *java-type*
> > >> > > for these 2 field types but I couldn't get any trace of how that
> > >> > not-empty
> > >> > > constraint is levied upon "id-ne" fields.
> > >> > >
> > >> > > I even looked at table structure for those fields having "id-ne"
> > field
> > >> > type
> > >> > > but there was no "not-null" constraint at even the database level.
> > >> > >
> > >> > > When dug into it further I can across this commit where validate
> > >> elements
> > >> > > were removed from fieldtype*.xml files.
> > >> > >
> > >> > >
> > >> > > http://markmail.org/message/otec62xiwkpjttkq
> > >> > >
> > >> > > http://svn.apache.org/viewvc?view=revision&revision=959708
> > >> > >
> > >> > > But I can't get why it was removed and when it was removed whether
> > >> there
> > >> > > was some implementation that took its place for those validations.
> > >> > >
> > >> > >
> > >> > > To further check if it even works I found an OOTB entity having a
> > >> > > non-primary key "id-ne" field. I found that "*Picklist*" entity
> has
> > a
> > >> > field
> > >> > > *shipmentMethodTypeId* as "id- ne" type. When we *create a
> picklist*
> > >> for
> > >> > an
> > >> > > order from Facility Manager, *shipmentMethodTypeId* can be
> *empty*.
> > >> > >
> > >> > >
> > >> > > If my explorations are correct currently there is no difference
> > >> between
> > >> > > "id" and "id-ne" at the implementation level and there should be a
> > >> Jira
> > >> > for
> > >> > > it.
> > >> > >
> > >> > > If I missed out something, can someone please enlighten me with
> that
> > >> and
> > >> > > help me understanding it well.
> > >> > >
> > >> > >
> > >> > > Thanks & Regards,
> > >> > > Aditya Sharma
> > >> > > Enterprise Software Engineer
> > >> > > HotWax Systems Pvt. Ltd.
> > >> > > http://www.hotwaxsystems.com/
> > >> > >
> > >> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Difference between "id" and "id-ne" field type
Posted by Scott Gray <sc...@hotwaxsystems.com>.
Took a while to dig it out but here it is:
http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
It's not as in-depth as I'd hoped, but it was purposefully removed all the
same.
Regards
Scott
On 3 May 2017 at 17:42, Aditya Sharma <ad...@hotwaxsystems.com>
wrote:
> Hi Scott,
>
> As there is very less information available with the commit I found it
> quite difficult to find that discussion. Maybe I just missed out something.
> Could you please just help me trace that out to understand it well?
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
> aditya.sharma@hotwaxsystems.com> wrote:
>
> > Hi Taher,
> >
> > Totally agreed to that it should be at entity engine level and default to
> > false as that way it will not affect the current implementations and will
> > give more scope for its enhancements to cater specific needs.
> >
> > > My recommendation is to reintroduce the validation attribute. However!
> > the
> > > validation IMO should happen at the entity engine level, not the
> database
> > > level (for not null), and also the default value should be false if
> > > omitted. We also need to think of the design in respect of the
> validation
> > > attributes and how they apply.
> > >
> >
> >
> > Thanks & Regards,
> > Aditya Sharma
> > Enterprise Software Engineer
> > HotWax Systems Pvt. Ltd.
> > http://www.hotwaxsystems.com/
> >
> > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >
> > On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
> scott.gray@hotwaxsystems.com>
> > wrote:
> >
> >> It was removed purposefully and there was a discussion about it. I'd
> >> suggest we all need to go back and look at that discussion before
> deciding
> >> how to proceed.
> >>
> >> Regards
> >> Scott
> >>
> >> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com>
> wrote:
> >>
> >> > I don't have the historical context, so please excuse if I'm off.
> >> >
> >> > My recommendation is to reintroduce the validation attribute. However!
> >> the
> >> > validation IMO should happen at the entity engine level, not the
> >> database
> >> > level (for not null), and also the default value should be false if
> >> > omitted. We also need to think of the design in respect of the
> >> validation
> >> > attributes and how they apply.
> >> >
> >> > On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> >> > aditya.sharma@hotwaxsystems.com> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > While creating an entity I was in ambiguity whether to go for "*id*"
> >> or "
> >> > > *id-ne*" field type. When I googled it I came across this very
> >> enriching
> >> > > discussion.
> >> > >
> >> > > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> >> > td2251546.html
> >> > >
> >> > > As stated, an "id-ne" field can only have a *non-empty* value.
> >> > >
> >> > > I was very curious to know how it is implemented in OFBiz. I found
> >> that
> >> > > almost all the *fieldtype*.xml* files have *same* *sql-type* and
> >> > > *java-type*
> >> > > for these 2 field types but I couldn't get any trace of how that
> >> > not-empty
> >> > > constraint is levied upon "id-ne" fields.
> >> > >
> >> > > I even looked at table structure for those fields having "id-ne"
> field
> >> > type
> >> > > but there was no "not-null" constraint at even the database level.
> >> > >
> >> > > When dug into it further I can across this commit where validate
> >> elements
> >> > > were removed from fieldtype*.xml files.
> >> > >
> >> > >
> >> > > http://markmail.org/message/otec62xiwkpjttkq
> >> > >
> >> > > http://svn.apache.org/viewvc?view=revision&revision=959708
> >> > >
> >> > > But I can't get why it was removed and when it was removed whether
> >> there
> >> > > was some implementation that took its place for those validations.
> >> > >
> >> > >
> >> > > To further check if it even works I found an OOTB entity having a
> >> > > non-primary key "id-ne" field. I found that "*Picklist*" entity has
> a
> >> > field
> >> > > *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist*
> >> for
> >> > an
> >> > > order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
> >> > >
> >> > >
> >> > > If my explorations are correct currently there is no difference
> >> between
> >> > > "id" and "id-ne" at the implementation level and there should be a
> >> Jira
> >> > for
> >> > > it.
> >> > >
> >> > > If I missed out something, can someone please enlighten me with that
> >> and
> >> > > help me understanding it well.
> >> > >
> >> > >
> >> > > Thanks & Regards,
> >> > > Aditya Sharma
> >> > > Enterprise Software Engineer
> >> > > HotWax Systems Pvt. Ltd.
> >> > > http://www.hotwaxsystems.com/
> >> > >
> >> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >> > >
> >> >
> >>
> >
> >
>
Re: Difference between "id" and "id-ne" field type
Posted by Jacques Le Roux <ja...@les7arts.com>.
Please help yourself: http://ofbiz.apache.org/mailing-lists.html
Jacques
Le 03/05/2017 à 13:25, William Cunningham a écrit :
> To: user@ofbiz.apache.org<ma...@ofbiz.apache.org>
>
> Could you remove me from the mailing list?
>
> Thanks
> Bill
>
>
> William Cunningham
> 15 Bernard Avenue
> Barrington, RI 02806
> 401-575-9164
> william.cunningham@live.com<ma...@live.com>
>
>
>
> On May 3, 2017, at 1:42 AM, Aditya Sharma <ad...@hotwaxsystems.com>> wrote:
>
> Hi Scott,
>
> As there is very less information available with the commit I found it
> quite difficult to find that discussion. Maybe I just missed out something.
> Could you please just help me trace that out to understand it well?
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
> aditya.sharma@hotwaxsystems.com> wrote:
>
> Hi Taher,
>
> Totally agreed to that it should be at entity engine level and default to
> false as that way it will not affect the current implementations and will
> give more scope for its enhancements to cater specific needs.
>
> My recommendation is to reintroduce the validation attribute. However!
> the
> validation IMO should happen at the entity engine level, not the database
> level (for not null), and also the default value should be false if
> omitted. We also need to think of the design in respect of the validation
> attributes and how they apply.
>
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <sc...@hotwaxsystems.com>
> wrote:
>
> It was removed purposefully and there was a discussion about it. I'd
> suggest we all need to go back and look at that discussion before deciding
> how to proceed.
>
> Regards
> Scott
>
> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com> wrote:
>
> I don't have the historical context, so please excuse if I'm off.
>
> My recommendation is to reintroduce the validation attribute. However!
> the
> validation IMO should happen at the entity engine level, not the
> database
> level (for not null), and also the default value should be false if
> omitted. We also need to think of the design in respect of the
> validation
> attributes and how they apply.
>
> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> aditya.sharma@hotwaxsystems.com> wrote:
>
> Hi,
>
> While creating an entity I was in ambiguity whether to go for "*id*"
> or "
> *id-ne*" field type. When I googled it I came across this very
> enriching
> discussion.
>
> http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> td2251546.html
>
> As stated, an "id-ne" field can only have a *non-empty* value.
>
> I was very curious to know how it is implemented in OFBiz. I found
> that
> almost all the *fieldtype*.xml* files have *same* *sql-type* and
> *java-type*
> for these 2 field types but I couldn't get any trace of how that
> not-empty
> constraint is levied upon "id-ne" fields.
>
> I even looked at table structure for those fields having "id-ne" field
> type
> but there was no "not-null" constraint at even the database level.
>
> When dug into it further I can across this commit where validate
> elements
> were removed from fieldtype*.xml files.
>
>
> http://markmail.org/message/otec62xiwkpjttkq
>
> http://svn.apache.org/viewvc?view=revision&revision=959708
>
> But I can't get why it was removed and when it was removed whether
> there
> was some implementation that took its place for those validations.
>
>
> To further check if it even works I found an OOTB entity having a
> non-primary key "id-ne" field. I found that "*Picklist*" entity has a
> field
> *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist*
> for
> an
> order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
>
>
> If my explorations are correct currently there is no difference
> between
> "id" and "id-ne" at the implementation level and there should be a
> Jira
> for
> it.
>
> If I missed out something, can someone please enlighten me with that
> and
> help me understanding it well.
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
>
>
>
>
>
>
Re: Difference between "id" and "id-ne" field type
Posted by William Cunningham <wi...@live.com>.
To: user@ofbiz.apache.org<ma...@ofbiz.apache.org>
Could you remove me from the mailing list?
Thanks
Bill
William Cunningham
15 Bernard Avenue
Barrington, RI 02806
401-575-9164
william.cunningham@live.com<ma...@live.com>
On May 3, 2017, at 1:42 AM, Aditya Sharma <ad...@hotwaxsystems.com>> wrote:
Hi Scott,
As there is very less information available with the commit I found it
quite difficult to find that discussion. Maybe I just missed out something.
Could you please just help me trace that out to understand it well?
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
aditya.sharma@hotwaxsystems.com> wrote:
Hi Taher,
Totally agreed to that it should be at entity engine level and default to
false as that way it will not affect the current implementations and will
give more scope for its enhancements to cater specific needs.
My recommendation is to reintroduce the validation attribute. However!
the
validation IMO should happen at the entity engine level, not the database
level (for not null), and also the default value should be false if
omitted. We also need to think of the design in respect of the validation
attributes and how they apply.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Tue, May 2, 2017 at 12:11 AM, Scott Gray <sc...@hotwaxsystems.com>
wrote:
It was removed purposefully and there was a discussion about it. I'd
suggest we all need to go back and look at that discussion before deciding
how to proceed.
Regards
Scott
On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com> wrote:
I don't have the historical context, so please excuse if I'm off.
My recommendation is to reintroduce the validation attribute. However!
the
validation IMO should happen at the entity engine level, not the
database
level (for not null), and also the default value should be false if
omitted. We also need to think of the design in respect of the
validation
attributes and how they apply.
On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
aditya.sharma@hotwaxsystems.com> wrote:
Hi,
While creating an entity I was in ambiguity whether to go for "*id*"
or "
*id-ne*" field type. When I googled it I came across this very
enriching
discussion.
http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
td2251546.html
As stated, an "id-ne" field can only have a *non-empty* value.
I was very curious to know how it is implemented in OFBiz. I found
that
almost all the *fieldtype*.xml* files have *same* *sql-type* and
*java-type*
for these 2 field types but I couldn't get any trace of how that
not-empty
constraint is levied upon "id-ne" fields.
I even looked at table structure for those fields having "id-ne" field
type
but there was no "not-null" constraint at even the database level.
When dug into it further I can across this commit where validate
elements
were removed from fieldtype*.xml files.
http://markmail.org/message/otec62xiwkpjttkq
http://svn.apache.org/viewvc?view=revision&revision=959708
But I can't get why it was removed and when it was removed whether
there
was some implementation that took its place for those validations.
To further check if it even works I found an OOTB entity having a
non-primary key "id-ne" field. I found that "*Picklist*" entity has a
field
*shipmentMethodTypeId* as "id- ne" type. When we *create a picklist*
for
an
order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
If my explorations are correct currently there is no difference
between
"id" and "id-ne" at the implementation level and there should be a
Jira
for
it.
If I missed out something, can someone please enlighten me with that
and
help me understanding it well.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
Re: Difference between "id" and "id-ne" field type
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
Hi Scott,
As there is very less information available with the commit I found it
quite difficult to find that discussion. Maybe I just missed out something.
Could you please just help me trace that out to understand it well?
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
aditya.sharma@hotwaxsystems.com> wrote:
> Hi Taher,
>
> Totally agreed to that it should be at entity engine level and default to
> false as that way it will not affect the current implementations and will
> give more scope for its enhancements to cater specific needs.
>
> > My recommendation is to reintroduce the validation attribute. However!
> the
> > validation IMO should happen at the entity engine level, not the database
> > level (for not null), and also the default value should be false if
> > omitted. We also need to think of the design in respect of the validation
> > attributes and how they apply.
> >
>
>
> Thanks & Regards,
> Aditya Sharma
> Enterprise Software Engineer
> HotWax Systems Pvt. Ltd.
> http://www.hotwaxsystems.com/
>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Tue, May 2, 2017 at 12:11 AM, Scott Gray <sc...@hotwaxsystems.com>
> wrote:
>
>> It was removed purposefully and there was a discussion about it. I'd
>> suggest we all need to go back and look at that discussion before deciding
>> how to proceed.
>>
>> Regards
>> Scott
>>
>> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com> wrote:
>>
>> > I don't have the historical context, so please excuse if I'm off.
>> >
>> > My recommendation is to reintroduce the validation attribute. However!
>> the
>> > validation IMO should happen at the entity engine level, not the
>> database
>> > level (for not null), and also the default value should be false if
>> > omitted. We also need to think of the design in respect of the
>> validation
>> > attributes and how they apply.
>> >
>> > On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
>> > aditya.sharma@hotwaxsystems.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > While creating an entity I was in ambiguity whether to go for "*id*"
>> or "
>> > > *id-ne*" field type. When I googled it I came across this very
>> enriching
>> > > discussion.
>> > >
>> > > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
>> > td2251546.html
>> > >
>> > > As stated, an "id-ne" field can only have a *non-empty* value.
>> > >
>> > > I was very curious to know how it is implemented in OFBiz. I found
>> that
>> > > almost all the *fieldtype*.xml* files have *same* *sql-type* and
>> > > *java-type*
>> > > for these 2 field types but I couldn't get any trace of how that
>> > not-empty
>> > > constraint is levied upon "id-ne" fields.
>> > >
>> > > I even looked at table structure for those fields having "id-ne" field
>> > type
>> > > but there was no "not-null" constraint at even the database level.
>> > >
>> > > When dug into it further I can across this commit where validate
>> elements
>> > > were removed from fieldtype*.xml files.
>> > >
>> > >
>> > > http://markmail.org/message/otec62xiwkpjttkq
>> > >
>> > > http://svn.apache.org/viewvc?view=revision&revision=959708
>> > >
>> > > But I can't get why it was removed and when it was removed whether
>> there
>> > > was some implementation that took its place for those validations.
>> > >
>> > >
>> > > To further check if it even works I found an OOTB entity having a
>> > > non-primary key "id-ne" field. I found that "*Picklist*" entity has a
>> > field
>> > > *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist*
>> for
>> > an
>> > > order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
>> > >
>> > >
>> > > If my explorations are correct currently there is no difference
>> between
>> > > "id" and "id-ne" at the implementation level and there should be a
>> Jira
>> > for
>> > > it.
>> > >
>> > > If I missed out something, can someone please enlighten me with that
>> and
>> > > help me understanding it well.
>> > >
>> > >
>> > > Thanks & Regards,
>> > > Aditya Sharma
>> > > Enterprise Software Engineer
>> > > HotWax Systems Pvt. Ltd.
>> > > http://www.hotwaxsystems.com/
>> > >
>> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>> > >
>> >
>>
>
>
Re: Difference between "id" and "id-ne" field type
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
Hi Taher,
Totally agreed to that it should be at entity engine level and default to
false as that way it will not affect the current implementations and will
give more scope for its enhancements to cater specific needs.
> My recommendation is to reintroduce the validation attribute. However! the
> validation IMO should happen at the entity engine level, not the database
> level (for not null), and also the default value should be false if
> omitted. We also need to think of the design in respect of the validation
> attributes and how they apply.
>
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Tue, May 2, 2017 at 12:11 AM, Scott Gray <sc...@hotwaxsystems.com>
wrote:
> It was removed purposefully and there was a discussion about it. I'd
> suggest we all need to go back and look at that discussion before deciding
> how to proceed.
>
> Regards
> Scott
>
> On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com> wrote:
>
> > I don't have the historical context, so please excuse if I'm off.
> >
> > My recommendation is to reintroduce the validation attribute. However!
> the
> > validation IMO should happen at the entity engine level, not the database
> > level (for not null), and also the default value should be false if
> > omitted. We also need to think of the design in respect of the validation
> > attributes and how they apply.
> >
> > On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> > aditya.sharma@hotwaxsystems.com> wrote:
> >
> > > Hi,
> > >
> > > While creating an entity I was in ambiguity whether to go for "*id*"
> or "
> > > *id-ne*" field type. When I googled it I came across this very
> enriching
> > > discussion.
> > >
> > > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> > td2251546.html
> > >
> > > As stated, an "id-ne" field can only have a *non-empty* value.
> > >
> > > I was very curious to know how it is implemented in OFBiz. I found that
> > > almost all the *fieldtype*.xml* files have *same* *sql-type* and
> > > *java-type*
> > > for these 2 field types but I couldn't get any trace of how that
> > not-empty
> > > constraint is levied upon "id-ne" fields.
> > >
> > > I even looked at table structure for those fields having "id-ne" field
> > type
> > > but there was no "not-null" constraint at even the database level.
> > >
> > > When dug into it further I can across this commit where validate
> elements
> > > were removed from fieldtype*.xml files.
> > >
> > >
> > > http://markmail.org/message/otec62xiwkpjttkq
> > >
> > > http://svn.apache.org/viewvc?view=revision&revision=959708
> > >
> > > But I can't get why it was removed and when it was removed whether
> there
> > > was some implementation that took its place for those validations.
> > >
> > >
> > > To further check if it even works I found an OOTB entity having a
> > > non-primary key "id-ne" field. I found that "*Picklist*" entity has a
> > field
> > > *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist*
> for
> > an
> > > order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
> > >
> > >
> > > If my explorations are correct currently there is no difference between
> > > "id" and "id-ne" at the implementation level and there should be a Jira
> > for
> > > it.
> > >
> > > If I missed out something, can someone please enlighten me with that
> and
> > > help me understanding it well.
> > >
> > >
> > > Thanks & Regards,
> > > Aditya Sharma
> > > Enterprise Software Engineer
> > > HotWax Systems Pvt. Ltd.
> > > http://www.hotwaxsystems.com/
> > >
> > > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> > >
> >
>
Re: Difference between "id" and "id-ne" field type
Posted by Scott Gray <sc...@hotwaxsystems.com>.
It was removed purposefully and there was a discussion about it. I'd
suggest we all need to go back and look at that discussion before deciding
how to proceed.
Regards
Scott
On 1/05/2017 19:03, "Taher Alkhateeb" <sl...@gmail.com> wrote:
> I don't have the historical context, so please excuse if I'm off.
>
> My recommendation is to reintroduce the validation attribute. However! the
> validation IMO should happen at the entity engine level, not the database
> level (for not null), and also the default value should be false if
> omitted. We also need to think of the design in respect of the validation
> attributes and how they apply.
>
> On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
> aditya.sharma@hotwaxsystems.com> wrote:
>
> > Hi,
> >
> > While creating an entity I was in ambiguity whether to go for "*id*" or "
> > *id-ne*" field type. When I googled it I came across this very enriching
> > discussion.
> >
> > http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
> td2251546.html
> >
> > As stated, an "id-ne" field can only have a *non-empty* value.
> >
> > I was very curious to know how it is implemented in OFBiz. I found that
> > almost all the *fieldtype*.xml* files have *same* *sql-type* and
> > *java-type*
> > for these 2 field types but I couldn't get any trace of how that
> not-empty
> > constraint is levied upon "id-ne" fields.
> >
> > I even looked at table structure for those fields having "id-ne" field
> type
> > but there was no "not-null" constraint at even the database level.
> >
> > When dug into it further I can across this commit where validate elements
> > were removed from fieldtype*.xml files.
> >
> >
> > http://markmail.org/message/otec62xiwkpjttkq
> >
> > http://svn.apache.org/viewvc?view=revision&revision=959708
> >
> > But I can't get why it was removed and when it was removed whether there
> > was some implementation that took its place for those validations.
> >
> >
> > To further check if it even works I found an OOTB entity having a
> > non-primary key "id-ne" field. I found that "*Picklist*" entity has a
> field
> > *shipmentMethodTypeId* as "id- ne" type. When we *create a picklist* for
> an
> > order from Facility Manager, *shipmentMethodTypeId* can be *empty*.
> >
> >
> > If my explorations are correct currently there is no difference between
> > "id" and "id-ne" at the implementation level and there should be a Jira
> for
> > it.
> >
> > If I missed out something, can someone please enlighten me with that and
> > help me understanding it well.
> >
> >
> > Thanks & Regards,
> > Aditya Sharma
> > Enterprise Software Engineer
> > HotWax Systems Pvt. Ltd.
> > http://www.hotwaxsystems.com/
> >
> > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >
>