Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Bhathiya Jayasekara]

On Tue, Jan 10, 2017 at 12:06 PM, Malintha Amarasinghe 
wrote:

> On Tue, Jan 10, 2017 at 12:03 PM, Bhathiya Jayasekara 
> wrote:
>
>>
>> On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> If we can fix this without breaking the user experience is ideal. But
>>> the problem I see is how can we manage those changes; are we going to do
>>> that in each and every query? If we miss one place that will introduce a
>>> bug. Is there any way we can manage this in a central manner?
>>>
>>
>> If we do this in model classes, we don't need to change anywhere else.
>>
> So we need to do this in all String variables in all models classes?
>

Yes.


> Are we going to do this in code generator level?
>

No, models are not auto generated. Here we are talking about core service
level, but not REST API level.

Thanks,
Bhathiya


>
> Thanks,
> Malintha
>
>>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> On Tue, Jan 10, 2017 at 11:46 AM, Ishara Cooray 
>>> wrote:
>>>
 IMO user experience is the most important thing and what ever the logic
 we have implemented should not do any difference in end user experience.
 Hence, keeping things simple, prefer using a space character if and
 only if user has provided an empty string. Otherwise keep the default
 value.



 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Tue, Jan 10, 2017 at 11:29 AM, Akalanka Pagoda Arachchi <
 darsha...@wso2.com> wrote:

> We can say that the string we use is a reserved keyword. In any
> complex system we have to have such restriction in order address these 
> kind
> of issues.
>
> On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe <
> malint...@wso2.com> wrote:
>
>>
>>
>> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> Replacing an empty string with a space is generally a bad practice
>>> in database perspective due to few reasons.
>>>
>>> 1. Issues with visibility (a DBA cannot tell the difference by
>>> directly looking at it)
>>> 2. As Madhawa pointed out, space is a different character and when
>>> we really want to represent a space in the column and differentiate 
>>> between
>>> the empty and the space, it will be impossible.
>>> 3. Adds processing complexity
>>>
>>> The suggestion to use a space for empty strings is actually to
>>> denote an empty string by a special character since empty string is not
>>> supported in Oracle. Therefore instead of using a meaningless space
>>> character which introduces more complexity why not use a special string
>>> such as NULL or EMPTY?
>>>
>> If we select a special string we should ensure that those will never
>> come as a user input; I am doubtful we can assume that always.. Otherwise
>> if a user give "NULL" as an input, it will come back as "" right?
>>
>>>
>>> Thanks,
>>> Akalanka.
>>>
>>> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara <
>>> madha...@wso2.com> wrote:
>>>
 So what will happen if the user sends a space? So It's better to
 add a configuration to avoid these situations. then user can handle 
 this.
 WDYT ?

 On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> To be more precise, if a user explicitly sends "" then we will set
> the value to space, enabling us to convert back to "".
>
> But if the field is not set(ignored by the user) then the default
> NULL will be saved. This will make things consistant across all DB's.
>
> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <
> uvin...@wso2.com> wrote:
>
>> Note that there is a clear break in the UX of the REST API if we
>> allow pass empty strings to Oracle(due to the conversion to NULL). 
>> Oracle
>> treats "" as NULL but this is incorrect in the REST/JSON world.
>>
>> If a user enters an empty string "" they will expect to get ""
>> back, which will not happen with Oracles default behaviour. 
>> Therefore in
>> order to keep consistency of the REST API I dont see an alternative 
>> other
>> than having space as the default value. We can get rid of the space 
>> when
>> returning by simply trimming the String so we don't need to have any
>> special filtering logic.
>>
>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> +1 to keep default as NULL instead of a space.

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Malintha Amarasinghe]

On Tue, Jan 10, 2017 at 12:03 PM, Bhathiya Jayasekara 
wrote:

>
> On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe  > wrote:
>
>> If we can fix this without breaking the user experience is ideal. But the
>> problem I see is how can we manage those changes; are we going to do that
>> in each and every query? If we miss one place that will introduce a bug. Is
>> there any way we can manage this in a central manner?
>>
>
> If we do this in model classes, we don't need to change anywhere else.
>
So we need to do this in all String variables in all models classes? Are we
going to do this in code generator level?

Thanks,
Malintha

>
> Thanks,
> Bhathiya
>
>
>>
>> On Tue, Jan 10, 2017 at 11:46 AM, Ishara Cooray  wrote:
>>
>>> IMO user experience is the most important thing and what ever the logic
>>> we have implemented should not do any difference in end user experience.
>>> Hence, keeping things simple, prefer using a space character if and only
>>> if user has provided an empty string. Otherwise keep the default value.
>>>
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Tue, Jan 10, 2017 at 11:29 AM, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 We can say that the string we use is a reserved keyword. In any complex
 system we have to have such restriction in order address these kind of
 issues.

 On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe <
 malint...@wso2.com> wrote:

>
>
> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> Replacing an empty string with a space is generally a bad practice in
>> database perspective due to few reasons.
>>
>> 1. Issues with visibility (a DBA cannot tell the difference by
>> directly looking at it)
>> 2. As Madhawa pointed out, space is a different character and when we
>> really want to represent a space in the column and differentiate between
>> the empty and the space, it will be impossible.
>> 3. Adds processing complexity
>>
>> The suggestion to use a space for empty strings is actually to denote
>> an empty string by a special character since empty string is not 
>> supported
>> in Oracle. Therefore instead of using a meaningless space character which
>> introduces more complexity why not use a special string such as NULL or
>> EMPTY?
>>
> If we select a special string we should ensure that those will never
> come as a user input; I am doubtful we can assume that always.. Otherwise
> if a user give "NULL" as an input, it will come back as "" right?
>
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara <
>> madha...@wso2.com> wrote:
>>
>>> So what will happen if the user sends a space? So It's better to add
>>> a configuration to avoid these situations. then user can handle this. 
>>> WDYT ?
>>>
>>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 To be more precise, if a user explicitly sends "" then we will set
 the value to space, enabling us to convert back to "".

 But if the field is not set(ignored by the user) then the default
 NULL will be saved. This will make things consistant across all DB's.

 On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> Note that there is a clear break in the UX of the REST API if we
> allow pass empty strings to Oracle(due to the conversion to NULL). 
> Oracle
> treats "" as NULL but this is incorrect in the REST/JSON world.
>
> If a user enters an empty string "" they will expect to get ""
> back, which will not happen with Oracles default behaviour. Therefore 
> in
> order to keep consistency of the REST API I dont see an alternative 
> other
> than having space as the default value. We can get rid of the space 
> when
> returning by simply trimming the String so we don't need to have any
> special filtering logic.
>
> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> +1 to keep default as NULL instead of a space.
>>
>> Having a space will require adding trimming logic to the
>> underlying code and methods like 'isNullOrEmpty' will bypass this 
>> string if
>> there's a space.
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray > > wrote:
>>

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Bhathiya Jayasekara]

On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe 
wrote:

> If we can fix this without breaking the user experience is ideal. But the
> problem I see is how can we manage those changes; are we going to do that
> in each and every query? If we miss one place that will introduce a bug. Is
> there any way we can manage this in a central manner?
>

If we do this in model classes, we don't need to change anywhere else.

Thanks,
Bhathiya


>
> On Tue, Jan 10, 2017 at 11:46 AM, Ishara Cooray  wrote:
>
>> IMO user experience is the most important thing and what ever the logic
>> we have implemented should not do any difference in end user experience.
>> Hence, keeping things simple, prefer using a space character if and only
>> if user has provided an empty string. Otherwise keep the default value.
>>
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Tue, Jan 10, 2017 at 11:29 AM, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> We can say that the string we use is a reserved keyword. In any complex
>>> system we have to have such restriction in order address these kind of
>>> issues.
>>>
>>> On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe <
>>> malint...@wso2.com> wrote:
>>>


 On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
 darsha...@wso2.com> wrote:

> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by
> directly looking at it)
> 2. As Madhawa pointed out, space is a different character and when we
> really want to represent a space in the column and differentiate between
> the empty and the space, it will be impossible.
> 3. Adds processing complexity
>
> The suggestion to use a space for empty strings is actually to denote
> an empty string by a special character since empty string is not supported
> in Oracle. Therefore instead of using a meaningless space character which
> introduces more complexity why not use a special string such as NULL or
> EMPTY?
>
 If we select a special string we should ensure that those will never
 come as a user input; I am doubtful we can assume that always.. Otherwise
 if a user give "NULL" as an input, it will come back as "" right?

>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara <
> madha...@wso2.com> wrote:
>
>> So what will happen if the user sends a space? So It's better to add
>> a configuration to avoid these situations. then user can handle this. 
>> WDYT ?
>>
>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> To be more precise, if a user explicitly sends "" then we will set
>>> the value to space, enabling us to convert back to "".
>>>
>>> But if the field is not set(ignored by the user) then the default
>>> NULL will be saved. This will make things consistant across all DB's.
>>>
>>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Note that there is a clear break in the UX of the REST API if we
 allow pass empty strings to Oracle(due to the conversion to NULL). 
 Oracle
 treats "" as NULL but this is incorrect in the REST/JSON world.

 If a user enters an empty string "" they will expect to get ""
 back, which will not happen with Oracles default behaviour. Therefore 
 in
 order to keep consistency of the REST API I dont see an alternative 
 other
 than having space as the default value. We can get rid of the space 
 when
 returning by simply trimming the String so we don't need to have any
 special filtering logic.

 On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
 darsha...@wso2.com> wrote:

> +1 to keep default as NULL instead of a space.
>
> Having a space will require adding trimming logic to the
> underlying code and methods like 'isNullOrEmpty' will bypass this 
> string if
> there's a space.
>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
> wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa <
>> isu...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Setting a default value for empty fields being sent seems to be
 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Malintha Amarasinghe]

If we can fix this without breaking the user experience is ideal. But the
problem I see is how can we manage those changes; are we going to do that
in each and every query? If we miss one place that will introduce a bug. Is
there any way we can manage this in a central manner?

On Tue, Jan 10, 2017 at 11:46 AM, Ishara Cooray  wrote:

> IMO user experience is the most important thing and what ever the logic we
> have implemented should not do any difference in end user experience.
> Hence, keeping things simple, prefer using a space character if and only
> if user has provided an empty string. Otherwise keep the default value.
>
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Tue, Jan 10, 2017 at 11:29 AM, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> We can say that the string we use is a reserved keyword. In any complex
>> system we have to have such restriction in order address these kind of
>> issues.
>>
>> On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>>
>>>
>>> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 Replacing an empty string with a space is generally a bad practice in
 database perspective due to few reasons.

 1. Issues with visibility (a DBA cannot tell the difference by directly
 looking at it)
 2. As Madhawa pointed out, space is a different character and when we
 really want to represent a space in the column and differentiate between
 the empty and the space, it will be impossible.
 3. Adds processing complexity

 The suggestion to use a space for empty strings is actually to denote
 an empty string by a special character since empty string is not supported
 in Oracle. Therefore instead of using a meaningless space character which
 introduces more complexity why not use a special string such as NULL or
 EMPTY?

>>> If we select a special string we should ensure that those will never
>>> come as a user input; I am doubtful we can assume that always.. Otherwise
>>> if a user give "NULL" as an input, it will come back as "" right?
>>>

 Thanks,
 Akalanka.

 On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara  wrote:

> So what will happen if the user sends a space? So It's better to add a
> configuration to avoid these situations. then user can handle this. WDYT ?
>
> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
> uvin...@wso2.com> wrote:
>
>> To be more precise, if a user explicitly sends "" then we will set
>> the value to space, enabling us to convert back to "".
>>
>> But if the field is not set(ignored by the user) then the default
>> NULL will be saved. This will make things consistant across all DB's.
>>
>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha > > wrote:
>>
>>> Note that there is a clear break in the UX of the REST API if we
>>> allow pass empty strings to Oracle(due to the conversion to NULL). 
>>> Oracle
>>> treats "" as NULL but this is incorrect in the REST/JSON world.
>>>
>>> If a user enters an empty string "" they will expect to get "" back,
>>> which will not happen with Oracles default behaviour. Therefore in 
>>> order to
>>> keep consistency of the REST API I dont see an alternative other than
>>> having space as the default value. We can get rid of the space when
>>> returning by simply trimming the String so we don't need to have any
>>> special filtering logic.
>>>
>>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 +1 to keep default as NULL instead of a space.

 Having a space will require adding trimming logic to the underlying
 code and methods like 'isNullOrEmpty' will bypass this string if 
 there's a
 space.

 Thanks,
 Akalanka.

 On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
 wrote:

>
>
> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa  > wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> Setting a default value for empty fields being sent seems to be
>>> best.
>>>
>>> Furthermore we can have default values set in our DTO objects in
>>> case a given field is omitted altogether.
>>>
>>> So handling both the above scenarios can overcome the limitation
>>> in Oracle.
>>>
>>> But I dont know if this is good for the REST 

[Dev] WSO2 Identity Server analytic username/password configuration

[Godwin Shrimal]

Hi All,

As described in [1] we need to configure username/password in
IsAnalytics-Publisher-wso2event-AuthenticationData.xml and
IsAnalytics-Publisher-wso2event-SessionData.xml files. How do we handle
when some user store has policies to change credentials periodically. Do we
have to change credentials in those configs file and restart Identity
Server all the time or do we have any alternative for this ?

[1]
https://docs.wso2.com/display/IS520/Prerequisites+to+Publish+Statistics#PrerequisitestoPublishStatistics-Configuringeventpublishers

Thanks
Godwin

-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Ishara Cooray]

IMO user experience is the most important thing and what ever the logic we
have implemented should not do any difference in end user experience.
Hence, keeping things simple, prefer using a space character if and only if
user has provided an empty string. Otherwise keep the default value.



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Jan 10, 2017 at 11:29 AM, Akalanka Pagoda Arachchi <
darsha...@wso2.com> wrote:

> We can say that the string we use is a reserved keyword. In any complex
> system we have to have such restriction in order address these kind of
> issues.
>
> On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe  > wrote:
>
>>
>>
>> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> Replacing an empty string with a space is generally a bad practice in
>>> database perspective due to few reasons.
>>>
>>> 1. Issues with visibility (a DBA cannot tell the difference by directly
>>> looking at it)
>>> 2. As Madhawa pointed out, space is a different character and when we
>>> really want to represent a space in the column and differentiate between
>>> the empty and the space, it will be impossible.
>>> 3. Adds processing complexity
>>>
>>> The suggestion to use a space for empty strings is actually to denote an
>>> empty string by a special character since empty string is not supported in
>>> Oracle. Therefore instead of using a meaningless space character which
>>> introduces more complexity why not use a special string such as NULL or
>>> EMPTY?
>>>
>> If we select a special string we should ensure that those will never come
>> as a user input; I am doubtful we can assume that always.. Otherwise if a
>> user give "NULL" as an input, it will come back as "" right?
>>
>>>
>>> Thanks,
>>> Akalanka.
>>>
>>> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara 
>>> wrote:
>>>
 So what will happen if the user sends a space? So It's better to add a
 configuration to avoid these situations. then user can handle this. WDYT ?

 On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> To be more precise, if a user explicitly sends "" then we will set the
> value to space, enabling us to convert back to "".
>
> But if the field is not set(ignored by the user) then the default NULL
> will be saved. This will make things consistant across all DB's.
>
> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
> wrote:
>
>> Note that there is a clear break in the UX of the REST API if we
>> allow pass empty strings to Oracle(due to the conversion to NULL). Oracle
>> treats "" as NULL but this is incorrect in the REST/JSON world.
>>
>> If a user enters an empty string "" they will expect to get "" back,
>> which will not happen with Oracles default behaviour. Therefore in order 
>> to
>> keep consistency of the REST API I dont see an alternative other than
>> having space as the default value. We can get rid of the space when
>> returning by simply trimming the String so we don't need to have any
>> special filtering logic.
>>
>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> +1 to keep default as NULL instead of a space.
>>>
>>> Having a space will require adding trimming logic to the underlying
>>> code and methods like 'isNullOrEmpty' will bypass this string if 
>>> there's a
>>> space.
>>>
>>> Thanks,
>>> Akalanka.
>>>
>>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
>>> wrote:
>>>


 On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
 wrote:

>
>
> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
> uvin...@wso2.com> wrote:
>
>> Setting a default value for empty fields being sent seems to be
>> best.
>>
>> Furthermore we can have default values set in our DTO objects in
>> case a given field is omitted altogether.
>>
>> So handling both the above scenarios can overcome the limitation
>> in Oracle.
>>
>> But I dont know if this is good for the REST API user experience,
>> when retrieving data that contains these default values.
>>
> Additionally this could affect the user experience in UIs as well.
>
> How about we just keep a default value to NULL in DB level and
> then filter it from UI? Since anyway Oracle treats zero length String 
> as
> NULLs, even if the user enters an empty String it will then be
> automatically. The rest API will still return the default value if 
> 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Akalanka Pagoda Arachchi]

We can say that the string we use is a reserved keyword. In any complex
system we have to have such restriction in order address these kind of
issues.

On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe 
wrote:

>
>
> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> Replacing an empty string with a space is generally a bad practice in
>> database perspective due to few reasons.
>>
>> 1. Issues with visibility (a DBA cannot tell the difference by directly
>> looking at it)
>> 2. As Madhawa pointed out, space is a different character and when we
>> really want to represent a space in the column and differentiate between
>> the empty and the space, it will be impossible.
>> 3. Adds processing complexity
>>
>> The suggestion to use a space for empty strings is actually to denote an
>> empty string by a special character since empty string is not supported in
>> Oracle. Therefore instead of using a meaningless space character which
>> introduces more complexity why not use a special string such as NULL or
>> EMPTY?
>>
> If we select a special string we should ensure that those will never come
> as a user input; I am doubtful we can assume that always.. Otherwise if a
> user give "NULL" as an input, it will come back as "" right?
>
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara 
>> wrote:
>>
>>> So what will happen if the user sends a space? So It's better to add a
>>> configuration to avoid these situations. then user can handle this. WDYT ?
>>>
>>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 To be more precise, if a user explicitly sends "" then we will set the
 value to space, enabling us to convert back to "".

 But if the field is not set(ignored by the user) then the default NULL
 will be saved. This will make things consistant across all DB's.

 On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
 wrote:

> Note that there is a clear break in the UX of the REST API if we allow
> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
> "" as NULL but this is incorrect in the REST/JSON world.
>
> If a user enters an empty string "" they will expect to get "" back,
> which will not happen with Oracles default behaviour. Therefore in order 
> to
> keep consistency of the REST API I dont see an alternative other than
> having space as the default value. We can get rid of the space when
> returning by simply trimming the String so we don't need to have any
> special filtering logic.
>
> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> +1 to keep default as NULL instead of a space.
>>
>> Having a space will require adding trimming logic to the underlying
>> code and methods like 'isNullOrEmpty' will bypass this string if there's 
>> a
>> space.
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
>>> wrote:
>>>


 On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> Setting a default value for empty fields being sent seems to be
> best.
>
> Furthermore we can have default values set in our DTO objects in
> case a given field is omitted altogether.
>
> So handling both the above scenarios can overcome the limitation
> in Oracle.
>
> But I dont know if this is good for the REST API user experience,
> when retrieving data that contains these default values.
>
 Additionally this could affect the user experience in UIs as well.

 How about we just keep a default value to NULL in DB level and then
 filter it from UI? Since anyway Oracle treats zero length String as 
 NULLs,
 even if the user enters an empty String it will then be automatically. 
 The
 rest API will still return the default value if invoked directly 
 though.

>>>
>>> +1 to keep default as NULL which is more natural
>>> Further rather than filtering in the UI, how about directly do it in
>>> the query itself using COALESCE() built-in function (which is an ANSI
>>> standard and better performing than IS NULL)
>>>
>>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
>>> value is null it will map to empty
>>>
>>>
>>>
> On 6 January 2017 at 15:28, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

On 10 January 2017 at 11:10, Akalanka Pagoda Arachchi 
wrote:

> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by directly
> looking at it)
> 2. As Madhawa pointed out, space is a different character and when we
> really want to represent a space in the column and differentiate between
> the empty and the space, it will be impossible.
> 3. Adds processing complexity
>
> The suggestion to use a space for empty strings is actually to denote an
> empty string by a special character since empty string is not supported in
> Oracle. Therefore instead of using a meaningless space character which
> introduces more complexity why not use a special string such as NULL or
> EMPTY?
>

These are good points, but by using a special string to represent an empty
string we don't avoid complexity to the code because we need to check the
value of what has been read from the DB and explicitly replace that with an
empty string before sending back to the client. This logic also breaks if
the user by chance sends that special string explicitly.

We have not found an elegant way of doing this that balances all sides. Its
a pity Oracle deviates from the standard practice of other DBs in this
regard.


>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara 
> wrote:
>
>> So what will happen if the user sends a space? So It's better to add a
>> configuration to avoid these situations. then user can handle this. WDYT ?
>>
>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> To be more precise, if a user explicitly sends "" then we will set the
>>> value to space, enabling us to convert back to "".
>>>
>>> But if the field is not set(ignored by the user) then the default NULL
>>> will be saved. This will make things consistant across all DB's.
>>>
>>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
>>> wrote:
>>>
 Note that there is a clear break in the UX of the REST API if we allow
 pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
 "" as NULL but this is incorrect in the REST/JSON world.

 If a user enters an empty string "" they will expect to get "" back,
 which will not happen with Oracles default behaviour. Therefore in order to
 keep consistency of the REST API I dont see an alternative other than
 having space as the default value. We can get rid of the space when
 returning by simply trimming the String so we don't need to have any
 special filtering logic.

 On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
 darsha...@wso2.com> wrote:

> +1 to keep default as NULL instead of a space.
>
> Having a space will require adding trimming logic to the underlying
> code and methods like 'isNullOrEmpty' will bypass this string if there's a
> space.
>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
> wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Setting a default value for empty fields being sent seems to be
 best.

 Furthermore we can have default values set in our DTO objects in
 case a given field is omitted altogether.

 So handling both the above scenarios can overcome the limitation in
 Oracle.

 But I dont know if this is good for the REST API user experience,
 when retrieving data that contains these default values.

>>> Additionally this could affect the user experience in UIs as well.
>>>
>>> How about we just keep a default value to NULL in DB level and then
>>> filter it from UI? Since anyway Oracle treats zero length String as 
>>> NULLs,
>>> even if the user enters an empty String it will then be automatically. 
>>> The
>>> rest API will still return the default value if invoked directly though.
>>>
>>
>> +1 to keep default as NULL which is more natural
>> Further rather than filtering in the UI, how about directly do it in
>> the query itself using COALESCE() built-in function (which is an ANSI
>> standard and better performing than IS NULL)
>>
>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
>> value is null it will map to empty
>>
>>
>>
 On 6 January 2017 at 15:28, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

>
>
> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Malintha Amarasinghe]

On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
darsha...@wso2.com> wrote:

> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by directly
> looking at it)
> 2. As Madhawa pointed out, space is a different character and when we
> really want to represent a space in the column and differentiate between
> the empty and the space, it will be impossible.
> 3. Adds processing complexity
>
> The suggestion to use a space for empty strings is actually to denote an
> empty string by a special character since empty string is not supported in
> Oracle. Therefore instead of using a meaningless space character which
> introduces more complexity why not use a special string such as NULL or
> EMPTY?
>
If we select a special string we should ensure that those will never come
as a user input; I am doubtful we can assume that always.. Otherwise if a
user give "NULL" as an input, it will come back as "" right?

>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara 
> wrote:
>
>> So what will happen if the user sends a space? So It's better to add a
>> configuration to avoid these situations. then user can handle this. WDYT ?
>>
>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> To be more precise, if a user explicitly sends "" then we will set the
>>> value to space, enabling us to convert back to "".
>>>
>>> But if the field is not set(ignored by the user) then the default NULL
>>> will be saved. This will make things consistant across all DB's.
>>>
>>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
>>> wrote:
>>>
 Note that there is a clear break in the UX of the REST API if we allow
 pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
 "" as NULL but this is incorrect in the REST/JSON world.

 If a user enters an empty string "" they will expect to get "" back,
 which will not happen with Oracles default behaviour. Therefore in order to
 keep consistency of the REST API I dont see an alternative other than
 having space as the default value. We can get rid of the space when
 returning by simply trimming the String so we don't need to have any
 special filtering logic.

 On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
 darsha...@wso2.com> wrote:

> +1 to keep default as NULL instead of a space.
>
> Having a space will require adding trimming logic to the underlying
> code and methods like 'isNullOrEmpty' will bypass this string if there's a
> space.
>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
> wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Setting a default value for empty fields being sent seems to be
 best.

 Furthermore we can have default values set in our DTO objects in
 case a given field is omitted altogether.

 So handling both the above scenarios can overcome the limitation in
 Oracle.

 But I dont know if this is good for the REST API user experience,
 when retrieving data that contains these default values.

>>> Additionally this could affect the user experience in UIs as well.
>>>
>>> How about we just keep a default value to NULL in DB level and then
>>> filter it from UI? Since anyway Oracle treats zero length String as 
>>> NULLs,
>>> even if the user enters an empty String it will then be automatically. 
>>> The
>>> rest API will still return the default value if invoked directly though.
>>>
>>
>> +1 to keep default as NULL which is more natural
>> Further rather than filtering in the UI, how about directly do it in
>> the query itself using COALESCE() built-in function (which is an ANSI
>> standard and better performing than IS NULL)
>>
>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
>> value is null it will map to empty
>>
>>
>>
 On 6 January 2017 at 15:28, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

>
>
> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> I faced $Subject in Oracle database while running integration
>> test on C5 on top.
>>
>> *Observation*
>>
>> when insert empty string ("") it was save as null in database.
>>
>> While going through SO I had found [1] , which did 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

This did come up in discussion. Functionally speaking a space is no
different to an empty String, though technically they are different. So it
will be a trade off to ignore explicitly sent spaces by users.

On 10 January 2017 at 11:01, Madhawa Gunasekara  wrote:

> So what will happen if the user sends a space? So It's better to add a
> configuration to avoid these situations. then user can handle this. WDYT ?
>
> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha  > wrote:
>
>> To be more precise, if a user explicitly sends "" then we will set the
>> value to space, enabling us to convert back to "".
>>
>> But if the field is not set(ignored by the user) then the default NULL
>> will be saved. This will make things consistant across all DB's.
>>
>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> Note that there is a clear break in the UX of the REST API if we allow
>>> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
>>> "" as NULL but this is incorrect in the REST/JSON world.
>>>
>>> If a user enters an empty string "" they will expect to get "" back,
>>> which will not happen with Oracles default behaviour. Therefore in order to
>>> keep consistency of the REST API I dont see an alternative other than
>>> having space as the default value. We can get rid of the space when
>>> returning by simply trimming the String so we don't need to have any
>>> special filtering logic.
>>>
>>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 +1 to keep default as NULL instead of a space.

 Having a space will require adding trimming logic to the underlying
 code and methods like 'isNullOrEmpty' will bypass this string if there's a
 space.

 Thanks,
 Akalanka.

 On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
 wrote:

>
>
> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> Setting a default value for empty fields being sent seems to be best.
>>>
>>> Furthermore we can have default values set in our DTO objects in
>>> case a given field is omitted altogether.
>>>
>>> So handling both the above scenarios can overcome the limitation in
>>> Oracle.
>>>
>>> But I dont know if this is good for the REST API user experience,
>>> when retrieving data that contains these default values.
>>>
>> Additionally this could affect the user experience in UIs as well.
>>
>> How about we just keep a default value to NULL in DB level and then
>> filter it from UI? Since anyway Oracle treats zero length String as 
>> NULLs,
>> even if the user enters an empty String it will then be automatically. 
>> The
>> rest API will still return the default value if invoked directly though.
>>
>
> +1 to keep default as NULL which is more natural
> Further rather than filtering in the UI, how about directly do it in
> the query itself using COALESCE() built-in function (which is an ANSI
> standard and better performing than IS NULL)
>
> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
> value is null it will map to empty
>
>
>
>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>


 On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> I faced $Subject in Oracle database while running integration test
> on C5 on top.
>
> *Observation*
>
> when insert empty string ("") it was save as null in database.
>
> While going through SO I had found [1] , which did happen in
> oracle database.
>
>
> We have come up with several ways to handle empty strings which
> user sends through the rest api.
>
> 1.  Validate the request and send error when giving empty strings
> 2.  Set default value like "N/A" into the fields which send as
> empty.
>
> Is there any other way to handle this problem ?.
>
> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
> string-in-oracle
>
> Thanks
>
>
> *Tharindu Dharmarathna*Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <+94%2077%20910%209091>*
>



 --

 *Tharindu Dharmarathna*Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Akalanka Pagoda Arachchi]

Replacing an empty string with a space is generally a bad practice in
database perspective due to few reasons.

1. Issues with visibility (a DBA cannot tell the difference by directly
looking at it)
2. As Madhawa pointed out, space is a different character and when we
really want to represent a space in the column and differentiate between
the empty and the space, it will be impossible.
3. Adds processing complexity

The suggestion to use a space for empty strings is actually to denote an
empty string by a special character since empty string is not supported in
Oracle. Therefore instead of using a meaningless space character which
introduces more complexity why not use a special string such as NULL or
EMPTY?

Thanks,
Akalanka.

On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara 
wrote:

> So what will happen if the user sends a space? So It's better to add a
> configuration to avoid these situations. then user can handle this. WDYT ?
>
> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha  > wrote:
>
>> To be more precise, if a user explicitly sends "" then we will set the
>> value to space, enabling us to convert back to "".
>>
>> But if the field is not set(ignored by the user) then the default NULL
>> will be saved. This will make things consistant across all DB's.
>>
>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> Note that there is a clear break in the UX of the REST API if we allow
>>> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
>>> "" as NULL but this is incorrect in the REST/JSON world.
>>>
>>> If a user enters an empty string "" they will expect to get "" back,
>>> which will not happen with Oracles default behaviour. Therefore in order to
>>> keep consistency of the REST API I dont see an alternative other than
>>> having space as the default value. We can get rid of the space when
>>> returning by simply trimming the String so we don't need to have any
>>> special filtering logic.
>>>
>>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 +1 to keep default as NULL instead of a space.

 Having a space will require adding trimming logic to the underlying
 code and methods like 'isNullOrEmpty' will bypass this string if there's a
 space.

 Thanks,
 Akalanka.

 On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
 wrote:

>
>
> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> Setting a default value for empty fields being sent seems to be best.
>>>
>>> Furthermore we can have default values set in our DTO objects in
>>> case a given field is omitted altogether.
>>>
>>> So handling both the above scenarios can overcome the limitation in
>>> Oracle.
>>>
>>> But I dont know if this is good for the REST API user experience,
>>> when retrieving data that contains these default values.
>>>
>> Additionally this could affect the user experience in UIs as well.
>>
>> How about we just keep a default value to NULL in DB level and then
>> filter it from UI? Since anyway Oracle treats zero length String as 
>> NULLs,
>> even if the user enters an empty String it will then be automatically. 
>> The
>> rest API will still return the default value if invoked directly though.
>>
>
> +1 to keep default as NULL which is more natural
> Further rather than filtering in the UI, how about directly do it in
> the query itself using COALESCE() built-in function (which is an ANSI
> standard and better performing than IS NULL)
>
> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
> value is null it will map to empty
>
>
>
>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>


 On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> I faced $Subject in Oracle database while running integration test
> on C5 on top.
>
> *Observation*
>
> when insert empty string ("") it was save as null in database.
>
> While going through SO I had found [1] , which did happen in
> oracle database.
>
>
> We have come up with several ways to handle empty strings which
> user sends through the rest api.
>
> 1.  Validate the request and send error when giving empty strings
> 2.  Set default value like "N/A" into the fields which send as
> empty.
>
> Is there any other way to handle this problem ?.
>
> [1] - 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Madhawa Gunasekara]

So what will happen if the user sends a space? So It's better to add a
configuration to avoid these situations. then user can handle this. WDYT ?

On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha 
wrote:

> To be more precise, if a user explicitly sends "" then we will set the
> value to space, enabling us to convert back to "".
>
> But if the field is not set(ignored by the user) then the default NULL
> will be saved. This will make things consistant across all DB's.
>
> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
> wrote:
>
>> Note that there is a clear break in the UX of the REST API if we allow
>> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
>> "" as NULL but this is incorrect in the REST/JSON world.
>>
>> If a user enters an empty string "" they will expect to get "" back,
>> which will not happen with Oracles default behaviour. Therefore in order to
>> keep consistency of the REST API I dont see an alternative other than
>> having space as the default value. We can get rid of the space when
>> returning by simply trimming the String so we don't need to have any
>> special filtering logic.
>>
>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi > > wrote:
>>
>>> +1 to keep default as NULL instead of a space.
>>>
>>> Having a space will require adding trimming logic to the underlying code
>>> and methods like 'isNullOrEmpty' will bypass this string if there's a space.
>>>
>>> Thanks,
>>> Akalanka.
>>>
>>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray 
>>> wrote:
>>>


 On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
 wrote:

>
>
> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
> uvin...@wso2.com> wrote:
>
>> Setting a default value for empty fields being sent seems to be best.
>>
>> Furthermore we can have default values set in our DTO objects in case
>> a given field is omitted altogether.
>>
>> So handling both the above scenarios can overcome the limitation in
>> Oracle.
>>
>> But I dont know if this is good for the REST API user experience,
>> when retrieving data that contains these default values.
>>
> Additionally this could affect the user experience in UIs as well.
>
> How about we just keep a default value to NULL in DB level and then
> filter it from UI? Since anyway Oracle treats zero length String as NULLs,
> even if the user enters an empty String it will then be automatically. The
> rest API will still return the default value if invoked directly though.
>

 +1 to keep default as NULL which is more natural
 Further rather than filtering in the UI, how about directly do it in
 the query itself using COALESCE() built-in function (which is an ANSI
 standard and better performing than IS NULL)

 eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value
 is null it will map to empty



>> On 6 January 2017 at 15:28, Tharindu Dharmarathna > > wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 I faced $Subject in Oracle database while running integration test
 on C5 on top.

 *Observation*

 when insert empty string ("") it was save as null in database.

 While going through SO I had found [1] , which did happen in oracle
 database.


 We have come up with several ways to handle empty strings which
 user sends through the rest api.

 1.  Validate the request and send error when giving empty strings
 2.  Set default value like "N/A" into the fields which send as
 empty.

 Is there any other way to handle this problem ?.

 [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
 string-in-oracle

 Thanks


 *Tharindu Dharmarathna*Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94779109091 <+94%2077%20910%209091>*

>>>
>>>
>>>
>>> --
>>>
>>> *Tharindu Dharmarathna*Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048 <+94%2071%20635%208048>* *
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> 

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

To be more precise, if a user explicitly sends "" then we will set the
value to space, enabling us to convert back to "".

But if the field is not set(ignored by the user) then the default NULL will
be saved. This will make things consistant across all DB's.

On 10 January 2017 at 10:41, Uvindra Dias Jayasinha 
wrote:

> Note that there is a clear break in the UX of the REST API if we allow
> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
> "" as NULL but this is incorrect in the REST/JSON world.
>
> If a user enters an empty string "" they will expect to get "" back, which
> will not happen with Oracles default behaviour. Therefore in order to keep
> consistency of the REST API I dont see an alternative other than having
> space as the default value. We can get rid of the space when returning by
> simply trimming the String so we don't need to have any special filtering
> logic.
>
> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi 
> wrote:
>
>> +1 to keep default as NULL instead of a space.
>>
>> Having a space will require adding trimming logic to the underlying code
>> and methods like 'isNullOrEmpty' will bypass this string if there's a space.
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray  wrote:
>>
>>>
>>>
>>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
>>> wrote:
>>>


 On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> Setting a default value for empty fields being sent seems to be best.
>
> Furthermore we can have default values set in our DTO objects in case
> a given field is omitted altogether.
>
> So handling both the above scenarios can overcome the limitation in
> Oracle.
>
> But I dont know if this is good for the REST API user experience, when
> retrieving data that contains these default values.
>
 Additionally this could affect the user experience in UIs as well.

 How about we just keep a default value to NULL in DB level and then
 filter it from UI? Since anyway Oracle treats zero length String as NULLs,
 even if the user enters an empty String it will then be automatically. The
 rest API will still return the default value if invoked directly though.

>>>
>>> +1 to keep default as NULL which is more natural
>>> Further rather than filtering in the UI, how about directly do it in the
>>> query itself using COALESCE() built-in function (which is an ANSI standard
>>> and better performing than IS NULL)
>>>
>>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value
>>> is null it will map to empty
>>>
>>>
>>>
> On 6 January 2017 at 15:28, Tharindu Dharmarathna 
> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> I faced $Subject in Oracle database while running integration test
>>> on C5 on top.
>>>
>>> *Observation*
>>>
>>> when insert empty string ("") it was save as null in database.
>>>
>>> While going through SO I had found [1] , which did happen in oracle
>>> database.
>>>
>>>
>>> We have come up with several ways to handle empty strings which user
>>> sends through the rest api.
>>>
>>> 1.  Validate the request and send error when giving empty strings
>>> 2.  Set default value like "N/A" into the fields which send as
>>> empty.
>>>
>>> Is there any other way to handle this problem ?.
>>>
>>> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
>>> string-in-oracle
>>>
>>> Thanks
>>>
>>>
>>> *Tharindu Dharmarathna*Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>
>>
>>
>>
>> --
>>
>> *Tharindu Dharmarathna*Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



 --
 Thanks and Regards,

 Isuru H.
 +94 716 358 048 <+94%2071%20635%208048>* *



 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Lahiru Cooray*
>>> Software Engineer
>>> WSO2, Inc.;http://wso2.com/
>>> lean.enterprise.middleware
>>>
>>> Mobile: +94 715 654154 <+94%2071%20565%204154>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Darshana Akalanka Pagoda Arachchi,*

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

Note that there is a clear break in the UX of the REST API if we allow pass
empty strings to Oracle(due to the conversion to NULL). Oracle treats "" as
NULL but this is incorrect in the REST/JSON world.

If a user enters an empty string "" they will expect to get "" back, which
will not happen with Oracles default behaviour. Therefore in order to keep
consistency of the REST API I dont see an alternative other than having
space as the default value. We can get rid of the space when returning by
simply trimming the String so we don't need to have any special filtering
logic.

On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi 
wrote:

> +1 to keep default as NULL instead of a space.
>
> Having a space will require adding trimming logic to the underlying code
> and methods like 'isNullOrEmpty' will bypass this string if there's a space.
>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray  wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha >> > wrote:
>>>
 Setting a default value for empty fields being sent seems to be best.

 Furthermore we can have default values set in our DTO objects in case a
 given field is omitted altogether.

 So handling both the above scenarios can overcome the limitation in
 Oracle.

 But I dont know if this is good for the REST API user experience, when
 retrieving data that contains these default values.

>>> Additionally this could affect the user experience in UIs as well.
>>>
>>> How about we just keep a default value to NULL in DB level and then
>>> filter it from UI? Since anyway Oracle treats zero length String as NULLs,
>>> even if the user enters an empty String it will then be automatically. The
>>> rest API will still return the default value if invoked directly though.
>>>
>>
>> +1 to keep default as NULL which is more natural
>> Further rather than filtering in the UI, how about directly do it in the
>> query itself using COALESCE() built-in function (which is an ANSI standard
>> and better performing than IS NULL)
>>
>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value
>> is null it will map to empty
>>
>>
>>
 On 6 January 2017 at 15:28, Tharindu Dharmarathna 
 wrote:

>
>
> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> I faced $Subject in Oracle database while running integration test on
>> C5 on top.
>>
>> *Observation*
>>
>> when insert empty string ("") it was save as null in database.
>>
>> While going through SO I had found [1] , which did happen in oracle
>> database.
>>
>>
>> We have come up with several ways to handle empty strings which user
>> sends through the rest api.
>>
>> 1.  Validate the request and send error when giving empty strings
>> 2.  Set default value like "N/A" into the fields which send as empty.
>>
>> Is there any other way to handle this problem ?.
>>
>> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
>> string-in-oracle
>>
>> Thanks
>>
>>
>> *Tharindu Dharmarathna*Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>
>
>
>
> --
>
> *Tharindu Dharmarathna*Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <+94%2077%20910%209091>*
>



 --
 Regards,
 Uvindra

 Mobile: 33962

>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> +94 716 358 048 <+94%2071%20635%208048>* *
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Lahiru Cooray*
>> Software Engineer
>> WSO2, Inc.;http://wso2.com/
>> lean.enterprise.middleware
>>
>> Mobile: +94 715 654154 <+94%2071%20565%204154>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Darshana Akalanka Pagoda Arachchi,*
> *Senior Software Engineer, WSO2*
> *+94777118016 <+94%2077%20711%208016>*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

Mobile: 33962
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Akalanka Pagoda Arachchi]

+1 to keep default as NULL instead of a space.

Having a space will require adding trimming logic to the underlying code
and methods like 'isNullOrEmpty' will bypass this string if there's a space.

Thanks,
Akalanka.

On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray  wrote:

>
>
> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa  wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> Setting a default value for empty fields being sent seems to be best.
>>>
>>> Furthermore we can have default values set in our DTO objects in case a
>>> given field is omitted altogether.
>>>
>>> So handling both the above scenarios can overcome the limitation in
>>> Oracle.
>>>
>>> But I dont know if this is good for the REST API user experience, when
>>> retrieving data that contains these default values.
>>>
>> Additionally this could affect the user experience in UIs as well.
>>
>> How about we just keep a default value to NULL in DB level and then
>> filter it from UI? Since anyway Oracle treats zero length String as NULLs,
>> even if the user enters an empty String it will then be automatically. The
>> rest API will still return the default value if invoked directly though.
>>
>
> +1 to keep default as NULL which is more natural
> Further rather than filtering in the UI, how about directly do it in the
> query itself using COALESCE() built-in function (which is an ANSI standard
> and better performing than IS NULL)
>
> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value is
> null it will map to empty
>
>
>
>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna 
>>> wrote:
>>>


 On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> I faced $Subject in Oracle database while running integration test on
> C5 on top.
>
> *Observation*
>
> when insert empty string ("") it was save as null in database.
>
> While going through SO I had found [1] , which did happen in oracle
> database.
>
>
> We have come up with several ways to handle empty strings which user
> sends through the rest api.
>
> 1.  Validate the request and send error when giving empty strings
> 2.  Set default value like "N/A" into the fields which send as empty.
>
> Is there any other way to handle this problem ?.
>
> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
> string-in-oracle
>
> Thanks
>
>
> *Tharindu Dharmarathna*Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <+94%2077%20910%209091>*
>



 --

 *Tharindu Dharmarathna*Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94779109091 <+94%2077%20910%209091>*

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048 <+94%2071%20635%208048>* *
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Lahiru Cooray*
> Software Engineer
> WSO2, Inc.;http://wso2.com/
> lean.enterprise.middleware
>
> Mobile: +94 715 654154 <+94%2071%20565%204154>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Darshana Akalanka Pagoda Arachchi,*
*Senior Software Engineer, WSO2*
*+94777118016*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Lahiru Cooray]

On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa  wrote:

>
>
> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha 
> wrote:
>
>> Setting a default value for empty fields being sent seems to be best.
>>
>> Furthermore we can have default values set in our DTO objects in case a
>> given field is omitted altogether.
>>
>> So handling both the above scenarios can overcome the limitation in
>> Oracle.
>>
>> But I dont know if this is good for the REST API user experience, when
>> retrieving data that contains these default values.
>>
> Additionally this could affect the user experience in UIs as well.
>
> How about we just keep a default value to NULL in DB level and then filter
> it from UI? Since anyway Oracle treats zero length String as NULLs, even if
> the user enters an empty String it will then be automatically. The rest API
> will still return the default value if invoked directly though.
>

+1 to keep default as NULL which is more natural
Further rather than filtering in the UI, how about directly do it in the
query itself using COALESCE() built-in function (which is an ANSI standard
and better performing than IS NULL)

eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value is
null it will map to empty



>> On 6 January 2017 at 15:28, Tharindu Dharmarathna 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 I faced $Subject in Oracle database while running integration test on
 C5 on top.

 *Observation*

 when insert empty string ("") it was save as null in database.

 While going through SO I had found [1] , which did happen in oracle
 database.


 We have come up with several ways to handle empty strings which user
 sends through the rest api.

 1.  Validate the request and send error when giving empty strings
 2.  Set default value like "N/A" into the fields which send as empty.

 Is there any other way to handle this problem ?.

 [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
 string-in-oracle

 Thanks


 *Tharindu Dharmarathna*Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94779109091 <+94%2077%20910%209091>*

>>>
>>>
>>>
>>> --
>>>
>>> *Tharindu Dharmarathna*Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048 <+94%2071%20635%208048>* *
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware

Mobile: +94 715 654154
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Supporting MongoDB as a Secondary Userstore : an Extension for WSO2 Platform

[Kathees Rajendram]

Hi Tharindu,

Yes. We can add this MongoDB user store as an extension to WSO2 Store.

Thanks,
Kathees

On Mon, Jan 9, 2017 at 5:33 PM, Tharindu Edirisinghe 
wrote:

> Thanks for sharing the thread Vinod.
>
> In our project we would focus only on the user management.
>
> However later we can integrate the analytics as well together to build a
> complete usecase.
>
>
>
>
> On Mon, Jan 9, 2017 at 5:20 PM, Vinod Kavinda  wrote:
>
>> Hi All,
>> FYI, there is another attempt for using MongoDB with WSO2 Analytics. See
>> the Dev mail thread [1].
>>
>> [1] - "[Dev] [MongoDB] MongoDB support for analytics"
>>
>> On Mon, Jan 9, 2017 at 12:30 PM, Asantha Thilina <
>> asanthathil...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am willing to contribute and January (30, 31) is ok for me for a
>>> meeting
>>>
>>> thanks,
>>> Asantha
>>>
>>> On Sun, Jan 8, 2017 at 10:20 PM, Tharindu Edirisinghe <
>>> tharin...@wso2.com> wrote:
>>>
 Hi Devs,

 Along with Google Summer of Code 2016, we initiated this project [1]
 for supporting MongoDB as a secondary userstore for WSO2 products.

 Asantha (CC'ed) here successfully completed the project where it
 supported IS 5.1.0. (for IS 5.2.0 we need to do some minor modification to
 get it to working and for IS 5.3.0 which is about to be released.. we'll
 have to do some more changes because the claim management API is changed).

 We cannot ship this with a WSO2 product, because it is not scalable.
 The end user might use a different version of MongoDB database or JDBC
 driver, releasing patches would be difficult if any bug is found etc.

 Therefore the best way is to develop it as a connector (extension) and
 publicly release to WSO2 store.

 For that, I am initiating this email where we can discuss on how to
 proceed with this.

 @Kathees - I hope you can take the ownership of this. We can get
 Asantha's help as well whenever necessary.

 My idea is to have a meeting for this during the last week of January
 (30,31) and come up with a plan.

 [1] https://docs.wso2.com/display/GSoC/Project+Proposals+for+201
 6#ProjectProposalsfor2016-Proposal21:[IS]DocumentBasedNoSQLS
 upportforWSO2IdentityServerDatabase

 Thanks,
 TharinduE

 --

 Tharindu Edirisinghe
 Senior Software Engineer | WSO2 Inc
 Platform Security Team
 Blog : tharindue.blogspot.com
 mobile : +94 775181586 <+94%2077%20518%201586>

>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Vinod Kavinda
>> Software Engineer
>> *WSO2 Inc. - lean . enterprise . middleware .*
>> Mobile : +94 (0) 712 415544
>> Blog : http://soatechflicks.blogspot.com/
>> [image: http://wso2.com/signature]
>> 
>>
>>
>
>
> --
>
> Tharindu Edirisinghe
> Senior Software Engineer | WSO2 Inc
> Platform Security Team
> Blog : tharindue.blogspot.com
> mobile : +94 775181586 <+94%2077%20518%201586>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Kathees
Software Engineer,
email: kath...@wso2.com
mobile: +94772596173
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MongoDB] MongoDB support for analytics

[Gimantha Bandara]

Hi Jose Maria,

Thank you very much for your contribution and for the detailed explanation
on how you have mapped the MongoDB concepts to implement.  Analytics
RecordStores. We will go through the two pull requests you have sent us and
will share our thoughts.

Thanks,
Gimantha

On Mon, Jan 9, 2017 at 1:49 PM JOSE MARIA ALVAREZ FERNANDEZ <
josemaria.alvarezfernan...@elcorteingles.es> wrote:

> Hi,
>
> I'm Jose Maria Alvarez, and I'm part of one of the biggest retailers in
> Spain, called "El Corte Ingles". As you may know, we have a project to
> include WSO API-GW in our current architecture, and as part of that, we
> faced a problem related to the fact that you don't support MongoDB as the
> database backend for analytics.
> As this NOSQL database is very popular in our company, and has a wide
> support in-house and outside, we have been working in developing a
> datasource for MongoDB to store analytics events inside that. We think we
> have finished the basic implementation, as all the tests are OK now (apart
> from analysing how to integrate the different configuration options that
> Mongo has), and we would like to share the idea behind the implementation
> with you.
>
> Basically, the principles are:
>
> - All that is a table in the RDBMS world is going to be a collection in
> Mongo.
> - There will be no support for partitioning inside
> the AnalyticsRecordStore, but left to sharding support in Mongo. We need to
> analyze the best key or compound key in the data to have better performance
> when writing, but this should be done apart from the code.
> - We use the tenantId and the tableName to create the collection name, as
> you do in Cassandra implementation.
> - The event will be saved with the default id created by mongo, and a
> field called arsId for the record ID field. The map with properties will be
> saved the same way it's saved in cassandra, leaving values as binaries.
>
> The rest is pretty straightforward. We have tested it also in a real
> installation (two docker instances, one for the API-GW, one for the
> APIM-Analytics), and we have done pull requests in carbon-data and
> carbon-analytics repositories to start analyzing this:
>
> https://github.com/wso2/carbon-data/pull/133
> https://github.com/wso2/carbon-analytics/pull/225
>
> Could you share with me your thoughts about the principles? Are they OK
> from your perspective?
> As you may know, Mongo has a 16MB limit for a document (record). Do you
> think that a real event in WSO2 can exceed that size? I've been speaking
> with Isabelle, that is helping us integrate the product, and she told us
> the events are very small (apart from any custom event we would like to
> store), but I would also like to get your thoughts on that.
>
> Thank you,
>
> Jose Maria.
>
>
>
>
>
>
> www.elcorteingles.es
>
>
>
>
>
>
>
>
> ---
>
>
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
>
> contener información confidencial, siendo para uso exclusivo del
>
> destinatario, quedando prohibida su divulgación copia o  distribución a
>
> terceros sin la autorización expresa del remitente. Si Vd. ha recibido
>
> este mensaje erróneamente, se ruega lo  notifique al remitente y
>
> proceda a su borrado.
>
> Gracias por su colaboración.
>
>
>
> This message (including any attachments) may contain confidential
>
> information. It is intended for use by the recipient only. Any
>
> dissemination, copying or distribution to third parties without the
>
> express consent of the sender is strictly prohibited. If you have
>
> received this message in error, please delete it immediately and
>
> notify the sender.
>
> Thank you for your collaboration.
>
>
>
>
>
> ___
>
> Dev mailing list
>
> Dev@wso2.org
>
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Pulasthi Mahawithana]

Hi all,

Thanks for testing WSO2 Identity Server 5.3.0-RC3. This vote passed with 22
+1s and 0 -1s.
We will proceed with WSO2 Identity Server 5.3.0 release.


-- 
*Pulasthi Mahawithana*
Senior Software Engineer
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: http://blog.pulasthi.org


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Eranda Rajapakshe]

Hi,

Tested the following,

   - Custom OAuth 2.0 grant-type
   - Integrated Windows Authentication (IWA) with Kerberos

[+] Stable - go ahead and release


On Mon, Jan 9, 2017 at 2:55 PM, Pulasthi Mahawithana 
wrote:

> Hi All,
>
> Tested the following,
>
>- Engaging access policies in authentication flow
>- Template XACML policies for authentication flow and rule based
>provisioning
>- XACML funtionalities and policy editor
>- SCIM user list with attributes and other SCIM operations
>- Prompt for missing values in claims
>
>  [+] Stable - go ahead and release
>
> On Mon, Jan 9, 2017 at 1:14 PM, Rasika Perera  wrote:
>
>> Tested out component version 5.7.0 with IoT pack.
>>
>>[+] Stable - go ahead and release
>>
>> On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:
>>
>>> Hi,
>>>
>>> Tested the following IS Analytics features with IS Runtime,
>>>
>>>- Login attempts analytics
>>>- Login session analytics
>>>- Suspicious login alerts
>>>- Customizing alerts using template manager
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Ashen
>>>
>>> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
>>> wrote:
>>>
 Hi,

 Tested following,

- Account recovery with notification
- Account recovery with security questions
- Recaptcha
- Self signup

 [+] Stable - go ahead and release

 Thanks,
 Thanuja

 On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
 wrote:

> Tested following features with MSSQL
>
> 1) SAML flow
> 2) OAuth
> 3) OIDC
> 4) SAML metedata profile
>
>   [+] Stable - go ahead and release
>
> Best Regards
> Rushmin
>
> On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera 
> wrote:
>
>> Hi,
>> I tested the following on the Identity Server 5.3.0-RC3 pack,
>>
>>- Discovery
>>- DCR
>>- Form Post
>>- Introspection
>>- SCIM API
>>- User Management
>>
>> Worked fine without any issues.
>> [+] Stable - go ahead and release
>>
>> On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
>> pulast...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>>>
>>> Please download, test the product and vote. Vote will be open for 72
>>> hours or as needed.
>>>
>>> This release fixes the following issues:
>>>
>>> Runtime : https://wso2.org/jira/issues/?filter=13612
>>> Analytics : https://wso2.org/jira/issues/?filter=13614
>>>
>>> Source and distribution
>>>
>>> Run-time : https://github.com/wso2/prod
>>> uct-is/releases/tag/v5.3.0-rc3
>>> Analytics : https://github.com/wso2/anal
>>> ytics-is/releases/tag/v5.3.0-rc3
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thanks,
>>> - WSO2 Identity Server Team -
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>>> Blog: http://blog.pulasthi.org
>>>
>>> 
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn 
>> Mobile: +94770198933 <+94%2077%20019%208933>
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Thanuja Lakmal*
 Senior Software Engineer
 WSO2 Inc. http://wso2.com/
 *lean.enterprise.middleware*
 Mobile: +94715979891 +94758009992

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Ashen 

Re: [Dev] Supporting MongoDB as a Secondary Userstore : an Extension for WSO2 Platform

[Tharindu Edirisinghe]

Thanks for sharing the thread Vinod.

In our project we would focus only on the user management.

However later we can integrate the analytics as well together to build a
complete usecase.




On Mon, Jan 9, 2017 at 5:20 PM, Vinod Kavinda  wrote:

> Hi All,
> FYI, there is another attempt for using MongoDB with WSO2 Analytics. See
> the Dev mail thread [1].
>
> [1] - "[Dev] [MongoDB] MongoDB support for analytics"
>
> On Mon, Jan 9, 2017 at 12:30 PM, Asantha Thilina  > wrote:
>
>> Hi all,
>>
>> I am willing to contribute and January (30, 31) is ok for me for a meeting
>>
>> thanks,
>> Asantha
>>
>> On Sun, Jan 8, 2017 at 10:20 PM, Tharindu Edirisinghe > > wrote:
>>
>>> Hi Devs,
>>>
>>> Along with Google Summer of Code 2016, we initiated this project [1] for
>>> supporting MongoDB as a secondary userstore for WSO2 products.
>>>
>>> Asantha (CC'ed) here successfully completed the project where it
>>> supported IS 5.1.0. (for IS 5.2.0 we need to do some minor modification to
>>> get it to working and for IS 5.3.0 which is about to be released.. we'll
>>> have to do some more changes because the claim management API is changed).
>>>
>>> We cannot ship this with a WSO2 product, because it is not scalable. The
>>> end user might use a different version of MongoDB database or JDBC driver,
>>> releasing patches would be difficult if any bug is found etc.
>>>
>>> Therefore the best way is to develop it as a connector (extension) and
>>> publicly release to WSO2 store.
>>>
>>> For that, I am initiating this email where we can discuss on how to
>>> proceed with this.
>>>
>>> @Kathees - I hope you can take the ownership of this. We can get
>>> Asantha's help as well whenever necessary.
>>>
>>> My idea is to have a meeting for this during the last week of January
>>> (30,31) and come up with a plan.
>>>
>>> [1] https://docs.wso2.com/display/GSoC/Project+Proposals+for+201
>>> 6#ProjectProposalsfor2016-Proposal21:[IS]DocumentBasedNoSQLS
>>> upportforWSO2IdentityServerDatabase
>>>
>>> Thanks,
>>> TharinduE
>>>
>>> --
>>>
>>> Tharindu Edirisinghe
>>> Senior Software Engineer | WSO2 Inc
>>> Platform Security Team
>>> Blog : tharindue.blogspot.com
>>> mobile : +94 775181586 <+94%2077%20518%201586>
>>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware .*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
> [image: http://wso2.com/signature]
> 
>
>


-- 

Tharindu Edirisinghe
Senior Software Engineer | WSO2 Inc
Platform Security Team
Blog : tharindue.blogspot.com
mobile : +94 775181586
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Supporting MongoDB as a Secondary Userstore : an Extension for WSO2 Platform

[Vinod Kavinda]

Hi All,
FYI, there is another attempt for using MongoDB with WSO2 Analytics. See
the Dev mail thread [1].

[1] - "[Dev] [MongoDB] MongoDB support for analytics"

On Mon, Jan 9, 2017 at 12:30 PM, Asantha Thilina 
wrote:

> Hi all,
>
> I am willing to contribute and January (30, 31) is ok for me for a meeting
>
> thanks,
> Asantha
>
> On Sun, Jan 8, 2017 at 10:20 PM, Tharindu Edirisinghe 
> wrote:
>
>> Hi Devs,
>>
>> Along with Google Summer of Code 2016, we initiated this project [1] for
>> supporting MongoDB as a secondary userstore for WSO2 products.
>>
>> Asantha (CC'ed) here successfully completed the project where it
>> supported IS 5.1.0. (for IS 5.2.0 we need to do some minor modification to
>> get it to working and for IS 5.3.0 which is about to be released.. we'll
>> have to do some more changes because the claim management API is changed).
>>
>> We cannot ship this with a WSO2 product, because it is not scalable. The
>> end user might use a different version of MongoDB database or JDBC driver,
>> releasing patches would be difficult if any bug is found etc.
>>
>> Therefore the best way is to develop it as a connector (extension) and
>> publicly release to WSO2 store.
>>
>> For that, I am initiating this email where we can discuss on how to
>> proceed with this.
>>
>> @Kathees - I hope you can take the ownership of this. We can get
>> Asantha's help as well whenever necessary.
>>
>> My idea is to have a meeting for this during the last week of January
>> (30,31) and come up with a plan.
>>
>> [1] https://docs.wso2.com/display/GSoC/Project+Proposals+for+201
>> 6#ProjectProposalsfor2016-Proposal21:[IS]DocumentBasedNoSQLS
>> upportforWSO2IdentityServerDatabase
>>
>> Thanks,
>> TharinduE
>>
>> --
>>
>> Tharindu Edirisinghe
>> Senior Software Engineer | WSO2 Inc
>> Platform Security Team
>> Blog : tharindue.blogspot.com
>> mobile : +94 775181586 <+94%2077%20518%201586>
>>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Vinod Kavinda
Software Engineer
*WSO2 Inc. - lean . enterprise . middleware .*
Mobile : +94 (0) 712 415544
Blog : http://soatechflicks.blogspot.com/
[image: http://wso2.com/signature]

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Pulasthi Mahawithana]

Hi All,

Tested the following,

   - Engaging access policies in authentication flow
   - Template XACML policies for authentication flow and rule based
   provisioning
   - XACML funtionalities and policy editor
   - SCIM user list with attributes and other SCIM operations
   - Prompt for missing values in claims

 [+] Stable - go ahead and release

On Mon, Jan 9, 2017 at 1:14 PM, Rasika Perera  wrote:

> Tested out component version 5.7.0 with IoT pack.
>
>[+] Stable - go ahead and release
>
> On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:
>
>> Hi,
>>
>> Tested the following IS Analytics features with IS Runtime,
>>
>>- Login attempts analytics
>>- Login session analytics
>>- Suspicious login alerts
>>- Customizing alerts using template manager
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Ashen
>>
>> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi,
>>>
>>> Tested following,
>>>
>>>- Account recovery with notification
>>>- Account recovery with security questions
>>>- Recaptcha
>>>- Self signup
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>>> wrote:
>>>
 Tested following features with MSSQL

 1) SAML flow
 2) OAuth
 3) OIDC
 4) SAML metedata profile

   [+] Stable - go ahead and release

 Best Regards
 Rushmin

 On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera 
 wrote:

> Hi,
> I tested the following on the Identity Server 5.3.0-RC3 pack,
>
>- Discovery
>- DCR
>- Form Post
>- Introspection
>- SCIM API
>- User Management
>
> Worked fine without any issues.
> [+] Stable - go ahead and release
>
> On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
> pulast...@wso2.com> wrote:
>
>> Hi All,
>>
>> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> This release fixes the following issues:
>>
>> Runtime : https://wso2.org/jira/issues/?filter=13612
>> Analytics : https://wso2.org/jira/issues/?filter=13614
>>
>> Source and distribution
>>
>> Run-time : https://github.com/wso2/prod
>> uct-is/releases/tag/v5.3.0-rc3
>> Analytics : https://github.com/wso2/anal
>> ytics-is/releases/tag/v5.3.0-rc3
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> - WSO2 Identity Server Team -
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Best Regards*

 *Rushmin Fernando*
 *Technical Lead*

 WSO2 Inc.  - Lean . Enterprise . Middleware

 mobile : +94775615183



 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Ashen Weerathunga*
>> Software Engineer
>> WSO2 Inc.: http://wso2.com
>> lean.enterprise.middleware
>>
>> Email: as...@wso2.com
>> Mobile: tel:94716042995 <94716042995>
>> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
>> *
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Danoja Dias]

Hi,

Tested the following IS features.

   1. PDF Support in IS analytics
   2. Email notifications on Security Alerts in IS analytics

[+] Stable - go ahead and release

On Mon, Jan 9, 2017 at 1:14 PM, Rasika Perera  wrote:

> Tested out component version 5.7.0 with IoT pack.
>
>[+] Stable - go ahead and release
>
> On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:
>
>> Hi,
>>
>> Tested the following IS Analytics features with IS Runtime,
>>
>>- Login attempts analytics
>>- Login session analytics
>>- Suspicious login alerts
>>- Customizing alerts using template manager
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Ashen
>>
>> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi,
>>>
>>> Tested following,
>>>
>>>- Account recovery with notification
>>>- Account recovery with security questions
>>>- Recaptcha
>>>- Self signup
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>>> wrote:
>>>
 Tested following features with MSSQL

 1) SAML flow
 2) OAuth
 3) OIDC
 4) SAML metedata profile

   [+] Stable - go ahead and release

 Best Regards
 Rushmin

 On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera 
 wrote:

> Hi,
> I tested the following on the Identity Server 5.3.0-RC3 pack,
>
>- Discovery
>- DCR
>- Form Post
>- Introspection
>- SCIM API
>- User Management
>
> Worked fine without any issues.
> [+] Stable - go ahead and release
>
> On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
> pulast...@wso2.com> wrote:
>
>> Hi All,
>>
>> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> This release fixes the following issues:
>>
>> Runtime : https://wso2.org/jira/issues/?filter=13612
>> Analytics : https://wso2.org/jira/issues/?filter=13614
>>
>> Source and distribution
>>
>> Run-time : https://github.com/wso2/prod
>> uct-is/releases/tag/v5.3.0-rc3
>> Analytics : https://github.com/wso2/anal
>> ytics-is/releases/tag/v5.3.0-rc3
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> - WSO2 Identity Server Team -
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Best Regards*

 *Rushmin Fernando*
 *Technical Lead*

 WSO2 Inc.  - Lean . Enterprise . Middleware

 mobile : +94775615183



 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Ashen Weerathunga*
>> Software Engineer
>> WSO2 Inc.: http://wso2.com
>> lean.enterprise.middleware
>>
>> Email: as...@wso2.com
>> Mobile: tel:94716042995 <94716042995>
>> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
>> *
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> With Regards,
>
> *Rasika Perera*
> Software Engineer
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> 
>
> WSO2 Inc. www.wso2.com
> 

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Harsha Kumara]

Tested following features in RC3

   - Install API Manager 6.0.37 features with IS RC3 pack
   - Tested API Creation, Application Creation, Key generation and API
   Invocation in both super tenant and tenant mode
   - Tested SSO of API Store and Publisher in both super tenant and tenant
   mode
   - Tested SSO with assertion encryption enabled of API Store and
   Publisher in both super tenant and tenant mode

[+] Stable - go ahead and release

On Mon, Jan 9, 2017 at 1:14 PM, Rasika Perera  wrote:

> Tested out component version 5.7.0 with IoT pack.
>
>[+] Stable - go ahead and release
>
> On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:
>
>> Hi,
>>
>> Tested the following IS Analytics features with IS Runtime,
>>
>>- Login attempts analytics
>>- Login session analytics
>>- Suspicious login alerts
>>- Customizing alerts using template manager
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Ashen
>>
>> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi,
>>>
>>> Tested following,
>>>
>>>- Account recovery with notification
>>>- Account recovery with security questions
>>>- Recaptcha
>>>- Self signup
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>>> wrote:
>>>
 Tested following features with MSSQL

 1) SAML flow
 2) OAuth
 3) OIDC
 4) SAML metedata profile

   [+] Stable - go ahead and release

 Best Regards
 Rushmin

 On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera 
 wrote:

> Hi,
> I tested the following on the Identity Server 5.3.0-RC3 pack,
>
>- Discovery
>- DCR
>- Form Post
>- Introspection
>- SCIM API
>- User Management
>
> Worked fine without any issues.
> [+] Stable - go ahead and release
>
> On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
> pulast...@wso2.com> wrote:
>
>> Hi All,
>>
>> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> This release fixes the following issues:
>>
>> Runtime : https://wso2.org/jira/issues/?filter=13612
>> Analytics : https://wso2.org/jira/issues/?filter=13614
>>
>> Source and distribution
>>
>> Run-time : https://github.com/wso2/prod
>> uct-is/releases/tag/v5.3.0-rc3
>> Analytics : https://github.com/wso2/anal
>> ytics-is/releases/tag/v5.3.0-rc3
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> - WSO2 Identity Server Team -
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Best Regards*

 *Rushmin Fernando*
 *Technical Lead*

 WSO2 Inc.  - Lean . Enterprise . Middleware

 mobile : +94775615183



 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Ashen Weerathunga*
>> Software Engineer
>> WSO2 Inc.: http://wso2.com
>> lean.enterprise.middleware
>>
>> Email: as...@wso2.com
>> Mobile: tel:94716042995 <94716042995>
>> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
>> *
>> 
>>
>> ___
>> 

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Lahiru Manohara]

Hi,

Tested the following IS features with Oracle database.

   1. Federation Facebook
   - SAML to Facebook.
  - OpenID to Facebook.
  - PassiveSTS to Facebook.
  - Claim Mappings.
   2. Federation Google
   - SAML to Google.
  - OpenID to Google.
  - PassiveSTS to Google.
  - Claim Mappings.
   3. Prompt for missing values in claims
  - Tested with a local authenticator and federated authenticators.

[+] Stable - go ahead and release

Best Regards,

On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:

> Hi,
>
> Tested the following IS Analytics features with IS Runtime,
>
>- Login attempts analytics
>- Login session analytics
>- Suspicious login alerts
>- Customizing alerts using template manager
>
> [+] Stable - go ahead and release
>
> Thanks,
> Ashen
>
> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
> wrote:
>
>> Hi,
>>
>> Tested following,
>>
>>- Account recovery with notification
>>- Account recovery with security questions
>>- Recaptcha
>>- Self signup
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Thanuja
>>
>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>> wrote:
>>
>>> Tested following features with MSSQL
>>>
>>> 1) SAML flow
>>> 2) OAuth
>>> 3) OIDC
>>> 4) SAML metedata profile
>>>
>>>   [+] Stable - go ahead and release
>>>
>>> Best Regards
>>> Rushmin
>>>
>>> On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera  wrote:
>>>
 Hi,
 I tested the following on the Identity Server 5.3.0-RC3 pack,

- Discovery
- DCR
- Form Post
- Introspection
- SCIM API
- User Management

 Worked fine without any issues.
 [+] Stable - go ahead and release

 On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

> Hi All,
>
> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
>
> This release fixes the following issues:
>
> Runtime : https://wso2.org/jira/issues/?filter=13612
> Analytics : https://wso2.org/jira/issues/?filter=13614
>
> Source and distribution
>
> Run-time : https://github.com/wso2/prod
> uct-is/releases/tag/v5.3.0-rc3
> Analytics : https://github.com/wso2/anal
> ytics-is/releases/tag/v5.3.0-rc3
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> - WSO2 Identity Server Team -
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022 <+94%2071%20517%209022>
> Blog: http://blog.pulasthi.org
>
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Dinali Rosemin Dabarera*
 Software Engineer
 WSO2 Lanka (pvt) Ltd.
 Web: http://wso2.com/
 Email : gdrdabar...@gmail.com
 LinkedIn 
 Mobile: +94770198933 <+94%2077%20019%208933>




 














 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Ashen Weerathunga*
> Software Engineer
> WSO2 Inc.: http://wso2.com
> lean.enterprise.middleware
>
> Email: as...@wso2.com
> Mobile: tel:94716042995 <94716042995>
> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
> *
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Lahiru Manohara*
*Software Engineer*
Mobile: +94716561576
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Rasika Perera]

Tested out component version 5.7.0 with IoT pack.

   [+] Stable - go ahead and release

On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:

> Hi,
>
> Tested the following IS Analytics features with IS Runtime,
>
>- Login attempts analytics
>- Login session analytics
>- Suspicious login alerts
>- Customizing alerts using template manager
>
> [+] Stable - go ahead and release
>
> Thanks,
> Ashen
>
> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
> wrote:
>
>> Hi,
>>
>> Tested following,
>>
>>- Account recovery with notification
>>- Account recovery with security questions
>>- Recaptcha
>>- Self signup
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Thanuja
>>
>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>> wrote:
>>
>>> Tested following features with MSSQL
>>>
>>> 1) SAML flow
>>> 2) OAuth
>>> 3) OIDC
>>> 4) SAML metedata profile
>>>
>>>   [+] Stable - go ahead and release
>>>
>>> Best Regards
>>> Rushmin
>>>
>>> On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera  wrote:
>>>
 Hi,
 I tested the following on the Identity Server 5.3.0-RC3 pack,

- Discovery
- DCR
- Form Post
- Introspection
- SCIM API
- User Management

 Worked fine without any issues.
 [+] Stable - go ahead and release

 On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

> Hi All,
>
> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
>
> This release fixes the following issues:
>
> Runtime : https://wso2.org/jira/issues/?filter=13612
> Analytics : https://wso2.org/jira/issues/?filter=13614
>
> Source and distribution
>
> Run-time : https://github.com/wso2/prod
> uct-is/releases/tag/v5.3.0-rc3
> Analytics : https://github.com/wso2/anal
> ytics-is/releases/tag/v5.3.0-rc3
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> - WSO2 Identity Server Team -
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022 <+94%2071%20517%209022>
> Blog: http://blog.pulasthi.org
>
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Dinali Rosemin Dabarera*
 Software Engineer
 WSO2 Lanka (pvt) Ltd.
 Web: http://wso2.com/
 Email : gdrdabar...@gmail.com
 LinkedIn 
 Mobile: +94770198933 <+94%2077%20019%208933>




 














 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Ashen Weerathunga*
> Software Engineer
> WSO2 Inc.: http://wso2.com
> lean.enterprise.middleware
>
> Email: as...@wso2.com
> Mobile: tel:94716042995 <94716042995>
> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
> *
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
With Regards,

*Rasika Perera*
Software Engineer
LinkedIn: http://lk.linkedin.com/in/rasika90



WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Darshana Gunawardana]

Tested following features in RC3.

   - XACML Rest profile
   - Rule base provisioning
   - Authorization Rules for SSO
   - Dynamic Client Registration


[+] Stable : Go ahead and release

Thanks,

On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga  wrote:

> Hi,
>
> Tested the following IS Analytics features with IS Runtime,
>
>- Login attempts analytics
>- Login session analytics
>- Suspicious login alerts
>- Customizing alerts using template manager
>
> [+] Stable - go ahead and release
>
> Thanks,
> Ashen
>
> On Mon, Jan 9, 2017 at 11:51 AM, Thanuja Jayasinghe 
> wrote:
>
>> Hi,
>>
>> Tested following,
>>
>>- Account recovery with notification
>>- Account recovery with security questions
>>- Recaptcha
>>- Self signup
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Thanuja
>>
>> On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando 
>> wrote:
>>
>>> Tested following features with MSSQL
>>>
>>> 1) SAML flow
>>> 2) OAuth
>>> 3) OIDC
>>> 4) SAML metedata profile
>>>
>>>   [+] Stable - go ahead and release
>>>
>>> Best Regards
>>> Rushmin
>>>
>>> On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera  wrote:
>>>
 Hi,
 I tested the following on the Identity Server 5.3.0-RC3 pack,

- Discovery
- DCR
- Form Post
- Introspection
- SCIM API
- User Management

 Worked fine without any issues.
 [+] Stable - go ahead and release

 On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

> Hi All,
>
> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
>
> This release fixes the following issues:
>
> Runtime : https://wso2.org/jira/issues/?filter=13612
> Analytics : https://wso2.org/jira/issues/?filter=13614
>
> Source and distribution
>
> Run-time : https://github.com/wso2/prod
> uct-is/releases/tag/v5.3.0-rc3
> Analytics : https://github.com/wso2/anal
> ytics-is/releases/tag/v5.3.0-rc3
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> - WSO2 Identity Server Team -
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022 <+94%2071%20517%209022>
> Blog: http://blog.pulasthi.org
>
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 *Dinali Rosemin Dabarera*
 Software Engineer
 WSO2 Lanka (pvt) Ltd.
 Web: http://wso2.com/
 Email : gdrdabar...@gmail.com
 LinkedIn 
 Mobile: +94770198933 <+94%2077%20019%208933>




 














 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Ashen Weerathunga*
> Software Engineer
> WSO2 Inc.: http://wso2.com
> lean.enterprise.middleware
>
> Email: as...@wso2.com
> Mobile: tel:94716042995 <94716042995>
> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
> *
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . Middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [MongoDB] MongoDB support for analytics

[JOSE MARIA ALVAREZ FERNANDEZ]

Hi,I'm Jose Maria Alvarez, and I'm part of one of the biggest retailers in Spain, called "El Corte Ingles". As you may know, we have a project to include WSO API-GW in our current architecture, and as part of that, we faced a problem related to the fact that you don't support MongoDB as the database backend for analytics. As this NOSQL database is very popular in our company, and has a wide support in-house and outside, we have been working in developing a datasource for MongoDB to store analytics events inside that. We think we have finished the basic implementation, as all the tests are OK now (apart from analysing how to integrate the different configuration options that Mongo has), and we would like to share the idea behind the implementation with you.Basically, the principles are:- All that is a table in the RDBMS world is going to be a collection in Mongo.- There will be no support for partitioning inside the AnalyticsRecordStore, but left to sharding support in Mongo. We need to analyze the best key or compound key in the data to have better performance when writing, but this should be done apart from the code.- We use the tenantId and the tableName to create the collection name, as you do in Cassandra implementation.- The event will be saved with the default id created by mongo, and a field called arsId for the record ID field. The map with properties will be saved the same way it's saved in cassandra, leaving values as binaries.The rest is pretty straightforward. We have tested it also in a real installation (two docker instances, one for the API-GW, one for the APIM-Analytics), and we have done pull requests in carbon-data and carbon-analytics repositories to start analyzing this:https://github.com/wso2/carbon-data/pull/133https://github.com/wso2/carbon-analytics/pull/225Could you share with me your thoughts about the principles? Are they OK from your perspective? As you may know, Mongo has a 16MB limit for a document (record). Do you think that a real event in WSO2 can exceed that size? I've been speaking with Isabelle, that is helping us integrate the product, and she told us the events are very small (apart from any custom event we would like to store), but I would also like to get your thoughts on that.Thank you,Jose Maria.

www.elcorteingles.es


---

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del 
destinatario, quedando prohibida su divulgación copia o  distribución a 
terceros sin la autorización expresa del remitente. Si Vd. ha recibido 
este mensaje erróneamente, se ruega lo  notifique al remitente y 
proceda a su borrado.
Gracias por su colaboración.

This message (including any attachments) may contain confidential 
information. It is intended for use by the recipient only. Any 
dissemination, copying or distribution to third parties without the 
express consent of the sender is strictly prohibited. If you have 
received this message in error, please delete it immediately and 
notify the sender. 
Thank you for your collaboration.
 

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev