Thanks Guys for the links,
I also agree we can now remove the useless id-ne, id-long-ne and id-vlong-ne
field-types (ie replace by corresponding id field-types)
We also need to clean the related embedded documentation. Like for instance for
"not-null" in fieldtypemodel.xsd
For the rest let it be, I don't think there is much more documentation about
that anyway.
Jacques
Le 04/05/2017 à 06:20, Scott Gray a écrit :
Chances are the field type was left for backwards compatibility. I'm ok
with it being removed though.
Regards
Scott
On 4 May 2017 at 15:32, Taher Alkhateeb <slidingfilame...@gmail.com> wrote:
Hmmm I was actually rethinking about this, and this reminds me somewhat of
the "Bounded context" concept from DDD. Some services might want to
validate while others don't on certain fields depending on context, and
hence delegating that validation to services makes sense (no domain exists
in OFBiz).
The problem of the existence of id-ne lingers though. It's putting
unneceasary cognitive strain on users to figure out what is it and what to
do with it. Also, this means no validation can happen for entity-auto CRUD
services.
So, I'm a bit on the fence, leaning slightly towards removing id-ne, but I
think we must choose one of:
1- removing id-ne
2- reintroducing validation
On May 4, 2017 3:10 AM, "Scott Gray" <scott.g...@hotwaxsystems.com> wrote:
Took a while to dig it out but here it is:
http://ofbiz.markmail.org/thread/c6ee3ewyo6jpik7k
It's not as in-depth as I'd hoped, but it was purposefully removed all
the
same.
Regards
Scott
On 3 May 2017 at 17:42, Aditya Sharma <aditya.sha...@hotwaxsystems.com>
wrote:
Hi Scott,
As there is very less information available with the commit I found it
quite difficult to find that discussion. Maybe I just missed out
something.
Could you please just help me trace that out to understand it well?
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Wed, May 3, 2017 at 11:03 AM, Aditya Sharma <
aditya.sha...@hotwaxsystems.com> wrote:
Hi Taher,
Totally agreed to that it should be at entity engine level and
default
to
false as that way it will not affect the current implementations and
will
give more scope for its enhancements to cater specific needs.
My recommendation is to reintroduce the validation attribute.
However!
the
validation IMO should happen at the entity engine level, not the
database
level (for not null), and also the default value should be false if
omitted. We also need to think of the design in respect of the
validation
attributes and how they apply.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Tue, May 2, 2017 at 12:11 AM, Scott Gray <
scott.g...@hotwaxsystems.com>
wrote:
It was removed purposefully and there was a discussion about it. I'd
suggest we all need to go back and look at that discussion before
deciding
how to proceed.
Regards
Scott
On 1/05/2017 19:03, "Taher Alkhateeb" <slidingfilame...@gmail.com>
wrote:
I don't have the historical context, so please excuse if I'm off.
My recommendation is to reintroduce the validation attribute.
However!
the
validation IMO should happen at the entity engine level, not the
database
level (for not null), and also the default value should be false
if
omitted. We also need to think of the design in respect of the
validation
attributes and how they apply.
On Sun, Apr 30, 2017 at 8:07 PM, Aditya Sharma <
aditya.sha...@hotwaxsystems.com> wrote:
Hi,
While creating an entity I was in ambiguity whether to go for
"*id*"
or "
*id-ne*" field type. When I googled it I came across this very
enriching
discussion.
http://ofbiz.135035.n4.nabble.com/EntityEngine-field-types-
td2251546.html
As stated, an "id-ne" field can only have a *non-empty* value.
I was very curious to know how it is implemented in OFBiz. I
found
that
almost all the *fieldtype*.xml* files have *same* *sql-type* and
*java-type*
for these 2 field types but I couldn't get any trace of how that
not-empty
constraint is levied upon "id-ne" fields.
I even looked at table structure for those fields having "id-ne"
field
type
but there was no "not-null" constraint at even the database
level.
When dug into it further I can across this commit where validate
elements
were removed from fieldtype*.xml files.
http://markmail.org/message/otec62xiwkpjttkq
http://svn.apache.org/viewvc?view=revision&revision=959708
But I can't get why it was removed and when it was removed
whether
there
was some implementation that took its place for those
validations.
To further check if it even works I found an OOTB entity having
a
non-primary key "id-ne" field. I found that "*Picklist*" entity
has
a
field
*shipmentMethodTypeId* as "id- ne" type. When we *create a
picklist*
for
an
order from Facility Manager, *shipmentMethodTypeId* can be
*empty*.
If my explorations are correct currently there is no difference
between
"id" and "id-ne" at the implementation level and there should
be a
Jira
for
it.
If I missed out something, can someone please enlighten me with
that
and
help me understanding it well.
Thanks & Regards,
Aditya Sharma
Enterprise Software Engineer
HotWax Systems Pvt. Ltd.
http://www.hotwaxsystems.com/
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
