+1 On Mon, May 8, 2017 at 10:52 AM, Deepak Dixit < [email protected]> 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 < > [email protected]> 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 < > >> [email protected]> 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 <[email protected]> > >>>> 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" <[email protected]> > >>>>> 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 <[email protected] > >>>>>> 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 < > >>>>>>> [email protected]> 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 < > >>>>>>>> > >>>>>>>> [email protected]> > >>>>>>> > >>>>>>> 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" < > [email protected]> > >>>>>>>>> > >>>>>>>>> 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 < > >>>>>>>>>> [email protected]> 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/> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > > >
