Re: Comparison semantics for complex types

[Mike Carey]

This is strictly a language question whose answer should have nothing to do
with implementation issues.  The = operator is valid - it's not an error if
its arguments are complex.



On Dec 29, 2017 9:20 PM, "Wail Alkowaileet"  wrote:

What I meant is that the user should explicitly call deep_equal. So we
should not implicitly call it if we found out we're comparing two complex
types. Therefore, I think we should throw an exception when an expression x
= y found and x and y are complex types. (probably guide the user to use
deep_equal instead).
The reason is when the compiler generates the plan for join using deep
equal, it picks nested loop join instead of hash join.
But If the type is known at runtime (open type) and we can implicitly call
deep_equal then we're not sure what join algorithm we should pick as x and
y can be of any type.

We need to compute the hash for the hash join to resolve hash(x) and
hash(y) equally. And I was thinking that it's a bit complex to have a hash
function for complex types (what would be the hash code for a multiset of
objects?)

Sorry for my bad explanation :-)


On Fri, Dec 29, 2017 at 8:47 PM, Taewoo Kim  wrote:

> I have two questions. How would you want to compare two complex objects?
> And why do we need to do a hash?
>
> On Fri, Dec 29, 2017 at 20:31 Wail Alkowaileet  wrote:
>
> > I think we should not call deep_equal implicitly when comparing objects,
> > arrays or multisets.
> > One reason is that we don't want to do hash join where the key is a
> complex
> > type (i.e what would be the hash function?).
> >
> > On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim  wrote:
> >
> > > @Heri: I'm sorry for not mentioning your deep_equal function. Yeah,
> > indeed,
> > > we have your function. I checked BuiltinFunctions and found the
> function
> > > named "deep-equal". So, we need to explicitly use that function to
> > conduct
> > > such comparison? If so, could you revise Wail's query? And it would be
> > nice
> > > if AsterixDB can call that function when it tries to compare arrays.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro 
> > > wrote:
> > >
> > > > Is this similar to the “deep_equal” function I implemented a while
> ago?
> > > >
> > > > -heri
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> > > > >
> > > > > Indeed - we need it someday!  (Sooner rather than later would be
> > nice.)
> > > > It basically needs to work like it does in languages like Python, I
> > > think.
> > > > (Cardinality and element by element equality for arrays, cardinality
> > and
> > > > order-independent equality for bags, field by field equality for
> > records,
> > > > and recursively through all of them.)
> > > > >
> > > > >
> > > > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > > > >> If I remember correctly, we don't support deep equality
comparison
> > in
> > > > >> AsterixDB yet.
> > > > >>
> > > > >> Best,
> > > > >> Taewoo
> > > > >>
> > > > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet <
> > wael@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Hi Devs,
> > > > >>>
> > > > >>> Currently we have an inconsistent behavior regarding the
> > comparators:
> > > > >>>
> > > > >>> In join, we allow such operation
> > > > >>>
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > > > >>> WHERE array1 = array2
> > > > >>>
> > > > >>> In select, an exception is thrown
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1
> > > > >>> WHERE array1 = [1]
> > > > >>>
> > > > >>> Error ASX0004: Unsupported type: comparison operations (>, >=,
<,
> > and
> > > > <=)
> > > > >>> cannot process input type array
> > > > >>>
> > > > >>> What should be the semantics for such operations?
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> *Regards,*
> > > > >>> Wail Alkowaileet
> > > > >>>
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Regards,*
> > Wail Alkowaileet
> >
>



--

*Regards,*
Wail Alkowaileet

Re: Comparison semantics for complex types

[Mike Carey]

This is strictly a language question whose answer should have nothing to do
with implementation issues.  The = operator is valid - it's not an error if
its arguments are complex.



On Dec 29, 2017 9:20 PM, "Wail Alkowaileet"  wrote:

What I meant is that the user should explicitly call deep_equal. So we
should not implicitly call it if we found out we're comparing two complex
types. Therefore, I think we should throw an exception when an expression x
= y found and x and y are complex types. (probably guide the user to use
deep_equal instead).
The reason is when the compiler generates the plan for join using deep
equal, it picks nested loop join instead of hash join.
But If the type is known at runtime (open type) and we can implicitly call
deep_equal then we're not sure what join algorithm we should pick as x and
y can be of any type.

We need to compute the hash for the hash join to resolve hash(x) and
hash(y) equally. And I was thinking that it's a bit complex to have a hash
function for complex types (what would be the hash code for a multiset of
objects?)

Sorry for my bad explanation :-)


On Fri, Dec 29, 2017 at 8:47 PM, Taewoo Kim  wrote:

> I have two questions. How would you want to compare two complex objects?
> And why do we need to do a hash?
>
> On Fri, Dec 29, 2017 at 20:31 Wail Alkowaileet  wrote:
>
> > I think we should not call deep_equal implicitly when comparing objects,
> > arrays or multisets.
> > One reason is that we don't want to do hash join where the key is a
> complex
> > type (i.e what would be the hash function?).
> >
> > On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim  wrote:
> >
> > > @Heri: I'm sorry for not mentioning your deep_equal function. Yeah,
> > indeed,
> > > we have your function. I checked BuiltinFunctions and found the
> function
> > > named "deep-equal". So, we need to explicitly use that function to
> > conduct
> > > such comparison? If so, could you revise Wail's query? And it would be
> > nice
> > > if AsterixDB can call that function when it tries to compare arrays.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro 
> > > wrote:
> > >
> > > > Is this similar to the “deep_equal” function I implemented a while
> ago?
> > > >
> > > > -heri
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> > > > >
> > > > > Indeed - we need it someday!  (Sooner rather than later would be
> > nice.)
> > > > It basically needs to work like it does in languages like Python, I
> > > think.
> > > > (Cardinality and element by element equality for arrays, cardinality
> > and
> > > > order-independent equality for bags, field by field equality for
> > records,
> > > > and recursively through all of them.)
> > > > >
> > > > >
> > > > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > > > >> If I remember correctly, we don't support deep equality
comparison
> > in
> > > > >> AsterixDB yet.
> > > > >>
> > > > >> Best,
> > > > >> Taewoo
> > > > >>
> > > > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet <
> > wael@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Hi Devs,
> > > > >>>
> > > > >>> Currently we have an inconsistent behavior regarding the
> > comparators:
> > > > >>>
> > > > >>> In join, we allow such operation
> > > > >>>
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > > > >>> WHERE array1 = array2
> > > > >>>
> > > > >>> In select, an exception is thrown
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1
> > > > >>> WHERE array1 = [1]
> > > > >>>
> > > > >>> Error ASX0004: Unsupported type: comparison operations (>, >=,
<,
> > and
> > > > <=)
> > > > >>> cannot process input type array
> > > > >>>
> > > > >>> What should be the semantics for such operations?
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> *Regards,*
> > > > >>> Wail Alkowaileet
> > > > >>>
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Regards,*
> > Wail Alkowaileet
> >
>



--

*Regards,*
Wail Alkowaileet

Re: Comparison semantics for complex types

[Wail Alkowaileet]

What I meant is that the user should explicitly call deep_equal. So we
should not implicitly call it if we found out we're comparing two complex
types. Therefore, I think we should throw an exception when an expression x
= y found and x and y are complex types. (probably guide the user to use
deep_equal instead).
The reason is when the compiler generates the plan for join using deep
equal, it picks nested loop join instead of hash join.
But If the type is known at runtime (open type) and we can implicitly call
deep_equal then we're not sure what join algorithm we should pick as x and
y can be of any type.

We need to compute the hash for the hash join to resolve hash(x) and
hash(y) equally. And I was thinking that it's a bit complex to have a hash
function for complex types (what would be the hash code for a multiset of
objects?)

Sorry for my bad explanation :-)


On Fri, Dec 29, 2017 at 8:47 PM, Taewoo Kim  wrote:

> I have two questions. How would you want to compare two complex objects?
> And why do we need to do a hash?
>
> On Fri, Dec 29, 2017 at 20:31 Wail Alkowaileet  wrote:
>
> > I think we should not call deep_equal implicitly when comparing objects,
> > arrays or multisets.
> > One reason is that we don't want to do hash join where the key is a
> complex
> > type (i.e what would be the hash function?).
> >
> > On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim  wrote:
> >
> > > @Heri: I'm sorry for not mentioning your deep_equal function. Yeah,
> > indeed,
> > > we have your function. I checked BuiltinFunctions and found the
> function
> > > named "deep-equal". So, we need to explicitly use that function to
> > conduct
> > > such comparison? If so, could you revise Wail's query? And it would be
> > nice
> > > if AsterixDB can call that function when it tries to compare arrays.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro 
> > > wrote:
> > >
> > > > Is this similar to the “deep_equal” function I implemented a while
> ago?
> > > >
> > > > -heri
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> > > > >
> > > > > Indeed - we need it someday!  (Sooner rather than later would be
> > nice.)
> > > > It basically needs to work like it does in languages like Python, I
> > > think.
> > > > (Cardinality and element by element equality for arrays, cardinality
> > and
> > > > order-independent equality for bags, field by field equality for
> > records,
> > > > and recursively through all of them.)
> > > > >
> > > > >
> > > > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > > > >> If I remember correctly, we don't support deep equality comparison
> > in
> > > > >> AsterixDB yet.
> > > > >>
> > > > >> Best,
> > > > >> Taewoo
> > > > >>
> > > > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet <
> > wael@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Hi Devs,
> > > > >>>
> > > > >>> Currently we have an inconsistent behavior regarding the
> > comparators:
> > > > >>>
> > > > >>> In join, we allow such operation
> > > > >>>
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > > > >>> WHERE array1 = array2
> > > > >>>
> > > > >>> In select, an exception is thrown
> > > > >>> SELECT *
> > > > >>> FROM [[1],[2],[3]] array1
> > > > >>> WHERE array1 = [1]
> > > > >>>
> > > > >>> Error ASX0004: Unsupported type: comparison operations (>, >=, <,
> > and
> > > > <=)
> > > > >>> cannot process input type array
> > > > >>>
> > > > >>> What should be the semantics for such operations?
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> *Regards,*
> > > > >>> Wail Alkowaileet
> > > > >>>
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Regards,*
> > Wail Alkowaileet
> >
>



-- 

*Regards,*
Wail Alkowaileet

Re: Comparison semantics for complex types

[Taewoo Kim]

I have two questions. How would you want to compare two complex objects?
And why do we need to do a hash?

On Fri, Dec 29, 2017 at 20:31 Wail Alkowaileet  wrote:

> I think we should not call deep_equal implicitly when comparing objects,
> arrays or multisets.
> One reason is that we don't want to do hash join where the key is a complex
> type (i.e what would be the hash function?).
>
> On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim  wrote:
>
> > @Heri: I'm sorry for not mentioning your deep_equal function. Yeah,
> indeed,
> > we have your function. I checked BuiltinFunctions and found the function
> > named "deep-equal". So, we need to explicitly use that function to
> conduct
> > such comparison? If so, could you revise Wail's query? And it would be
> nice
> > if AsterixDB can call that function when it tries to compare arrays.
> >
> > Best,
> > Taewoo
> >
> > On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro 
> > wrote:
> >
> > > Is this similar to the “deep_equal” function I implemented a while ago?
> > >
> > > -heri
> > >
> > > Sent from my iPhone
> > >
> > > > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> > > >
> > > > Indeed - we need it someday!  (Sooner rather than later would be
> nice.)
> > > It basically needs to work like it does in languages like Python, I
> > think.
> > > (Cardinality and element by element equality for arrays, cardinality
> and
> > > order-independent equality for bags, field by field equality for
> records,
> > > and recursively through all of them.)
> > > >
> > > >
> > > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > > >> If I remember correctly, we don't support deep equality comparison
> in
> > > >> AsterixDB yet.
> > > >>
> > > >> Best,
> > > >> Taewoo
> > > >>
> > > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet <
> wael@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >>> Hi Devs,
> > > >>>
> > > >>> Currently we have an inconsistent behavior regarding the
> comparators:
> > > >>>
> > > >>> In join, we allow such operation
> > > >>>
> > > >>> SELECT *
> > > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > > >>> WHERE array1 = array2
> > > >>>
> > > >>> In select, an exception is thrown
> > > >>> SELECT *
> > > >>> FROM [[1],[2],[3]] array1
> > > >>> WHERE array1 = [1]
> > > >>>
> > > >>> Error ASX0004: Unsupported type: comparison operations (>, >=, <,
> and
> > > <=)
> > > >>> cannot process input type array
> > > >>>
> > > >>> What should be the semantics for such operations?
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> *Regards,*
> > > >>> Wail Alkowaileet
> > > >>>
> > > >
> > >
> >
>
>
>
> --
>
> *Regards,*
> Wail Alkowaileet
>

Re: Comparison semantics for complex types

[Wail Alkowaileet]

I think we should not call deep_equal implicitly when comparing objects,
arrays or multisets.
One reason is that we don't want to do hash join where the key is a complex
type (i.e what would be the hash function?).

On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim  wrote:

> @Heri: I'm sorry for not mentioning your deep_equal function. Yeah, indeed,
> we have your function. I checked BuiltinFunctions and found the function
> named "deep-equal". So, we need to explicitly use that function to conduct
> such comparison? If so, could you revise Wail's query? And it would be nice
> if AsterixDB can call that function when it tries to compare arrays.
>
> Best,
> Taewoo
>
> On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro 
> wrote:
>
> > Is this similar to the “deep_equal” function I implemented a while ago?
> >
> > -heri
> >
> > Sent from my iPhone
> >
> > > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> > >
> > > Indeed - we need it someday!  (Sooner rather than later would be nice.)
> > It basically needs to work like it does in languages like Python, I
> think.
> > (Cardinality and element by element equality for arrays, cardinality and
> > order-independent equality for bags, field by field equality for records,
> > and recursively through all of them.)
> > >
> > >
> > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > >> If I remember correctly, we don't support deep equality comparison in
> > >> AsterixDB yet.
> > >>
> > >> Best,
> > >> Taewoo
> > >>
> > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet  >
> > >> wrote:
> > >>
> > >>> Hi Devs,
> > >>>
> > >>> Currently we have an inconsistent behavior regarding the comparators:
> > >>>
> > >>> In join, we allow such operation
> > >>>
> > >>> SELECT *
> > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > >>> WHERE array1 = array2
> > >>>
> > >>> In select, an exception is thrown
> > >>> SELECT *
> > >>> FROM [[1],[2],[3]] array1
> > >>> WHERE array1 = [1]
> > >>>
> > >>> Error ASX0004: Unsupported type: comparison operations (>, >=, <, and
> > <=)
> > >>> cannot process input type array
> > >>>
> > >>> What should be the semantics for such operations?
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> *Regards,*
> > >>> Wail Alkowaileet
> > >>>
> > >
> >
>



-- 

*Regards,*
Wail Alkowaileet

Re: Comparison semantics for complex types

[Taewoo Kim]

@Heri: I'm sorry for not mentioning your deep_equal function. Yeah, indeed,
we have your function. I checked BuiltinFunctions and found the function
named "deep-equal". So, we need to explicitly use that function to conduct
such comparison? If so, could you revise Wail's query? And it would be nice
if AsterixDB can call that function when it tries to compare arrays.

Best,
Taewoo

On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro  wrote:

> Is this similar to the “deep_equal” function I implemented a while ago?
>
> -heri
>
> Sent from my iPhone
>
> > On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> >
> > Indeed - we need it someday!  (Sooner rather than later would be nice.)
> It basically needs to work like it does in languages like Python, I think.
> (Cardinality and element by element equality for arrays, cardinality and
> order-independent equality for bags, field by field equality for records,
> and recursively through all of them.)
> >
> >
> >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> >> If I remember correctly, we don't support deep equality comparison in
> >> AsterixDB yet.
> >>
> >> Best,
> >> Taewoo
> >>
> >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet 
> >> wrote:
> >>
> >>> Hi Devs,
> >>>
> >>> Currently we have an inconsistent behavior regarding the comparators:
> >>>
> >>> In join, we allow such operation
> >>>
> >>> SELECT *
> >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> >>> WHERE array1 = array2
> >>>
> >>> In select, an exception is thrown
> >>> SELECT *
> >>> FROM [[1],[2],[3]] array1
> >>> WHERE array1 = [1]
> >>>
> >>> Error ASX0004: Unsupported type: comparison operations (>, >=, <, and
> <=)
> >>> cannot process input type array
> >>>
> >>> What should be the semantics for such operations?
> >>>
> >>>
> >>> --
> >>>
> >>> *Regards,*
> >>> Wail Alkowaileet
> >>>
> >
>

Re: Comparison semantics for complex types

[Heri Ramampiaro]

Is this similar to the “deep_equal” function I implemented a while ago? 

-heri 

Sent from my iPhone

> On Dec 29, 2017, at 17:23, Mike Carey  wrote:
> 
> Indeed - we need it someday!  (Sooner rather than later would be nice.)  It 
> basically needs to work like it does in languages like Python, I think.  
> (Cardinality and element by element equality for arrays, cardinality and 
> order-independent equality for bags, field by field equality for records, and 
> recursively through all of them.)
> 
> 
>> On 12/28/17 11:14 PM, Taewoo Kim wrote:
>> If I remember correctly, we don't support deep equality comparison in
>> AsterixDB yet.
>> 
>> Best,
>> Taewoo
>> 
>> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet 
>> wrote:
>> 
>>> Hi Devs,
>>> 
>>> Currently we have an inconsistent behavior regarding the comparators:
>>> 
>>> In join, we allow such operation
>>> 
>>> SELECT *
>>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
>>> WHERE array1 = array2
>>> 
>>> In select, an exception is thrown
>>> SELECT *
>>> FROM [[1],[2],[3]] array1
>>> WHERE array1 = [1]
>>> 
>>> Error ASX0004: Unsupported type: comparison operations (>, >=, <, and <=)
>>> cannot process input type array
>>> 
>>> What should be the semantics for such operations?
>>> 
>>> 
>>> --
>>> 
>>> *Regards,*
>>> Wail Alkowaileet
>>> 
> 

Re: Comparison semantics for complex types

[Mike Carey]

Indeed - we need it someday!  (Sooner rather than later would be nice.)  
It basically needs to work like it does in languages like Python, I 
think.  (Cardinality and element by element equality for arrays, 
cardinality and order-independent equality for bags, field by field 
equality for records, and recursively through all of them.)



On 12/28/17 11:14 PM, Taewoo Kim wrote:

If I remember correctly, we don't support deep equality comparison in
AsterixDB yet.

Best,
Taewoo

On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet 
wrote:


Hi Devs,

Currently we have an inconsistent behavior regarding the comparators:

In join, we allow such operation

SELECT *
FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
WHERE array1 = array2

In select, an exception is thrown
SELECT *
FROM [[1],[2],[3]] array1
WHERE array1 = [1]

Error ASX0004: Unsupported type: comparison operations (>, >=, <, and <=)
cannot process input type array

What should be the semantics for such operations?


--

*Regards,*
Wail Alkowaileet

Re: Comparison semantics for complex types

[Taewoo Kim]

If I remember correctly, we don't support deep equality comparison in
AsterixDB yet.

Best,
Taewoo

On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet 
wrote:

> Hi Devs,
>
> Currently we have an inconsistent behavior regarding the comparators:
>
> In join, we allow such operation
>
> SELECT *
> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> WHERE array1 = array2
>
> In select, an exception is thrown
> SELECT *
> FROM [[1],[2],[3]] array1
> WHERE array1 = [1]
>
> Error ASX0004: Unsupported type: comparison operations (>, >=, <, and <=)
> cannot process input type array
>
> What should be the semantics for such operations?
>
>
> --
>
> *Regards,*
> Wail Alkowaileet
>

Comparison semantics for complex types

[Wail Alkowaileet]

Hi Devs,

Currently we have an inconsistent behavior regarding the comparators:

In join, we allow such operation

SELECT *
FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
WHERE array1 = array2

In select, an exception is thrown
SELECT *
FROM [[1],[2],[3]] array1
WHERE array1 = [1]

Error ASX0004: Unsupported type: comparison operations (>, >=, <, and <=)
cannot process input type array

What should be the semantics for such operations?


-- 

*Regards,*
Wail Alkowaileet