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.r...@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 <slidingfilame...@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" <scott.g...@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.sha...@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.sha...@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.g...@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" <slidingfilame...@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.sha...@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/> >>>>>>>>> >>>>>>>>> >>>>>> >
