Difference between "id" and "id-ne" field type

[Aditya Sharma]

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/>

[taher]

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 <
[hidden email]> 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/>
>

[Scott Gray-3]

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" <[hidden email]> 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 <
> [hidden email]> 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/>
> >
>

[Aditya Sharma]

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 <[hidden email]>
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" <[hidden email]> 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 <
> > [hidden email]> 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/>
> > >
> >
>

[Aditya Sharma]

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 <
[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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 <
>> > [hidden email]> 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/>
>> > >
>> >
>>
>
>

[William Cunningham]

To: [hidden email]<mailto:[hidden email]>

Could you remove me from the mailing list?

Thanks
Bill


William Cunningham
15 Bernard Avenue
Barrington, RI 02806
401-575-9164
[hidden email]<mailto:[hidden email]>



On May 3, 2017, at 1:42 AM, Aditya Sharma <[hidden email]<mailto:[hidden email]>> 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 <
[hidden email]> 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 <[hidden email]>
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" <[hidden email]> 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 <
[hidden email]> 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/>

[Jacques Le Roux]

Please help yourself: http://ofbiz.apache.org/mailing-lists.html

Jacques


Le 03/05/2017 à 13:25, William Cunningham a écrit :

> To: [hidden email]<mailto:[hidden email]>
>
> Could you remove me from the mailing list?
>
> Thanks
> Bill
>
>
> William Cunningham
> 15 Bernard Avenue
> Barrington, RI 02806
> 401-575-9164
> [hidden email]<mailto:[hidden email]>
>
>
>
> On May 3, 2017, at 1:42 AM, Aditya Sharma <[hidden email]<mailto:[hidden email]>> 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 <
> [hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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 <
> [hidden email]> 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/>
>
>
>
>
>
>
>

[Scott Gray-3]

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 <[hidden email]>
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 <
> [hidden email]> 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 <
> [hidden email]>
> > 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" <[hidden email]>
> 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 <
> >> > [hidden email]> 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/>
> >> > >
> >> >
> >>
> >
> >
>

[taher]

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" <[hidden email]> 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 <[hidden email]>
> 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 <
> > [hidden email]> 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 <
> > [hidden email]>
> > > 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" <[hidden email]>
> > 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 <
> > >> > [hidden email]> 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/>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

[Scott Gray-3]

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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> > 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 <
> > > [hidden email]> 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 <
> > > [hidden email]>
> > > > 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" <[hidden email]>
> > > 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 <
> > > >> > [hidden email]> 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/>
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

[Jacques Le Roux]

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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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 <
>>>> [hidden email]> 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 <
>>>> [hidden email]>
>>>>> 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" <[hidden email]>
>>>> 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 <
>>>>>>> [hidden email]> 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/>
>>>>>>>>
>>>>>

[Aditya Sharma]

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 <
[hidden email]> 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 <[hidden email]>
>> 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" <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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 <
>>>>> [hidden email]> 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 <
>>>>>>
>>>>> [hidden email]>
>>>>>
>>>>>> 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" <[hidden email]>
>>>>>>>
>>>>>> 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 <
>>>>>>>> [hidden email]> 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/>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>

[Jacques Le Roux]

+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 <
> [hidden email]> 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 <[hidden email]>
>>> 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" <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>>>>
>>>>>> [hidden email]>
>>>>>>
>>>>>>> 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" <[hidden email]>
>>>>>>>>
>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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/>
>>>>>>>>>>
>>>>>>>>>>

[Deepak Dixit-3]

+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 <
[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]>
>>>> 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" <[hidden email]>
>>>>> 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 <[hidden email]
>>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>>
>>>>>>>> [hidden email]>
>>>>>>>
>>>>>>> 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" <[hidden email]>
>>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]> 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/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>

[taher]

+1

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

[Jacques Le Roux]

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 <
> [hidden email]> 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 <[hidden email]>
>>> 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" <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>>>>
>>>>>> [hidden email]>
>>>>>>
>>>>>>> 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" <[hidden email]>
>>>>>>>>
>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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/>
>>>>>>>>>>
>>>>>>>>>>

[Aditya Sharma]

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 <
[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]>
>>>> 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" <[hidden email]>
>>>>> 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 <[hidden email]
>>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>>
>>>>>>>> [hidden email]>
>>>>>>>
>>>>>>> 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" <[hidden email]>
>>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]> 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/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>

[Jacques Le Roux]

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 <
> [hidden email]> 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 <
>>> [hidden email]> 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 <[hidden email]>
>>>>> 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" <[hidden email]>
>>>>>> 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 <[hidden email]
>>>>>>> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>>> [hidden email]> 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/>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

[Aditya Sharma]

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 <
[hidden email]> 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 <
>> [hidden email]> 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 <
>>>> [hidden email]> 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 <[hidden email]>
>>>>>> 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" <[hidden email]>
>>>>>>> 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 <[hidden email]
>>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>
>>>>>>>>>> [hidden email]>
>>>>>>>>>>
>>>>>>>>> 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" <
>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>>> [hidden email]> 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/
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>