array_type_field_filter: Add new contains filter to search on Array type field

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos

[shubhisood]

• Adds new filter named as contains.
• This filter will search on Array type fields in Postgres DB.

Include references to all related GitHub issues and other pull requests, for example:

Fixes#342

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[shubhisood]

After adding this we do not need juggler related PR.
PFB PR Link:
loopbackio/loopback-datasource-juggler#1865

[bajtos]

I like how it's possible to implement your desired feature inside the connector only 👍

I have few comments on implementation details, PTAL above.

Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings).

[bajtos]

Suggested change

	should.not.exist(err);
	if(err)returndone(err);

That way the original error details and the stack trace is preserved.

[shubhisood]

How we would be handling this with async await type test case? @bajtos
I was thinking to write test case this way for handling failure of testcase with proper details.

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;try{constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);}catch(err){should.not.exist(err);}});

Please tell me if it is correct, I will update current test case in this way only.

[bajtos]

As a rule of thumb, the tests should pass any unexpected error to the test runner:

• Use done(err) when using callback
• Use regular error propagation when using async functions

it('should support where filter for array type field',async()=>{Post.dataSource.settings.allowExtendedOperators=true;constpost=awaitPost.find({where: {categories: {'contains': ['AA']},}});should.exist(post);post.length.should.equal(1);});

[bajtos]

The new version looks pretty good.

1. Please change the commit message to use the new operator name

2. Please add a new section to README to explain what extended operators are supported (e.g. @>) and what is needed to allow the app to use them (set allowExtendedOperators in model and/or datasource settings). Put yourself in the shoes of other LoopBack users - where would you look for information about contains operator and what info would you want to see to help you understand how to use this feature in your app?

[shubhisood]

@bajtos Thanks for review..

For Point#1 I have done the update.
For Point#2, I have following queries:

• In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

[bajtos]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

[shubhisood]

In which section of readme should I add this operator, As in current readme I couldn't find currently supported operators of postgres in this connector.

That's a good question. I believe the postgres connector so far supports only built-in LoopBack operators supported by all (or most?) connectors, so there was no need to explicitly list extended operators.

Now that you are implementing the first extended operator, I think you should simply add a new section. You can draw inspiration from MongoDB connector README:

• The section Additional properties mentions the configuration setting allowExtendedOperators and the extended operators unlocked by this option
• The section Update operators adds more details

In the case of PostgreSQL and your new contains operator, we can either call the section something like Query operators or perhaps a more generic Extended operators.

@bajtos Added the readme section for the new contains operator, Can you review it...

[bajtos]

Thank you @shubhisood for the update. I pushed few more commits to fix the failing builds and improve README content. Let's wait for CI results before landing.

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

Landed, thank you @shubhisood for the contribution ❤️

[shubhisood]

Landed, thank you @shubhisood for the contribution

Thanks for merging @bajtos