Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DAO consistency when deleting specific entities #107

Closed
2 tasks done
subnetmarco opened this issue Apr 2, 2015 · 1 comment
Closed
2 tasks done

DAO consistency when deleting specific entities #107

subnetmarco opened this issue Apr 2, 2015 · 1 comment
Assignees
Milestone

Comments

@subnetmarco
Copy link
Member

  • When deleting a consumer, also delete all the associated plugins_configurations and associated plugin-specific table rows.
  • When deleting an api, also delete all the associated plugins_configurations and associated plugin-specific table rows.
@subnetmarco subnetmarco added this to the 0.2.0 milestone Apr 2, 2015
@subnetmarco subnetmarco modified the milestones: 0.2.1, 0.2.0 Apr 24, 2015
@thibaultcha thibaultcha self-assigned this Apr 29, 2015
@subnetmarco subnetmarco added the dao label May 1, 2015
thibaultcha added a commit that referenced this issue May 4, 2015
This proposes a way to delete all `plugins_configurations` related to
`Consumers` or `APIs` when deleting one of the two later.

`:delete()` is simply overridden to iterate over all related
`plugins_configuration` and delete them one by one.

Caveats:
- I am very unhappy with how painful it is to use one DAO inside another
DAO. To avoid what would appear to be a cycling reference I rather opted
for instanciating a new DAO inside of the `delete` method.
- It is painful to perform a paginated query through the base_dao.
- It is even more painful to perform a find_by_keys query as a paginated
  query.
@thibaultcha
Copy link
Member

Wouldn't label this as a bug since it is simply something that was never implemented.

#198 Is a valid implementation of both those use cases. However, it raises concerns about the DAO which feels like it could be improved now that our usage of it evolved so much. I will try to improve it before merging it.

thibaultcha added a commit that referenced this issue May 6, 2015
[feature] cascade delete of plugins_configurations. fix #107
thibaultcha added a commit that referenced this issue Aug 25, 2015
This implements a "delete hook" system to trigger cascade deletion of
foreign rows in Cassandra. To do so, all foreign columns (representing foreign keys) must now be queryable (which means be indexed by Cassandra).

A "delete hook" is added to a parent DAO if any other DAO has foreign
rows to that DAO. Ex: APIs are parents to plugins_credentials, hence the
`apis` DAO will have a delete hook on the deletion of a row, to also
delete any related `plugins_configurations`.

- Move cascade delete tests to another file, with all use cases of
  current cascade deletion.
- Add a migration for oauth2 plugin to index the `consumer_id` field.
- Remove obsolete overridden delete methods of apis and consumers DAOs.

This should be a solution to #438 and is an improved implementation of #107
ctranxuan pushed a commit to streamdataio/kong that referenced this issue Aug 25, 2015
This proposes a way to delete all `plugins_configurations` related to
`Consumers` or `APIs` when deleting one of the two later.

`:delete()` is simply overridden to iterate over all related
`plugins_configuration` and delete them one by one.

Caveats:
- I am very unhappy with how painful it is to use one DAO inside another
DAO. To avoid what would appear to be a cycling reference I rather opted
for instanciating a new DAO inside of the `delete` method.
- It is painful to perform a paginated query through the base_dao.
- It is even more painful to perform a find_by_keys query as a paginated
  query.
ctranxuan pushed a commit to streamdataio/kong that referenced this issue Aug 25, 2015
[feature] cascade delete of plugins_configurations. fix Kong#107
gszr pushed a commit that referenced this issue Aug 18, 2021
### chore(session) bump lua-resty-session from 3.6 to 3.8
#### 3.8 - 2021-01-04
##### Added
- Connection options are now passed to `redis cluster client` as well.

#### 3.7 - 2020-10-27
##### Fixed
- Fix #107 where `session.start` could release a lock for a short period

#### Added
- Add `keep_lock` argument to `session.open`
- Add pluggable compressors, and implement `none` and `zlib` compressor

### chore(session) release 2.4.4

- bump the `lua-resty-session` from `3.6` to `3.8`
- add `endpoint_key` to admin api, see #30
hutchic added a commit that referenced this issue Jun 10, 2022
* fix(kind) switch from minikube to kind

* fix(ci) kind / helm compatibility fix

* fix(ci) adjust installation order

* fix(ci) install helm

* fix(ci) define clone location

* fix(ci) cleanup travis.yml file

* fix(ci) background the ci test setup steps

* fix(ci) wait until the k8s cluster is ready
bungle added a commit that referenced this issue May 10, 2023
### Summary

#### [0.8.22] - 2023-04-26
##### bug fixes
- **crypto:** use OPENSSL_free in BoringSSL ([#107](fffonion/lua-resty-openssl#107)) [7830212](fffonion/lua-resty-openssl@7830212)

<a name="0.8.21"></a>
#### [0.8.21] - 2023-03-24
##### features
- **x509.store:** extend verify to support setting flags ([#104](fffonion/lua-resty-openssl#104)) [fa45b6c](fffonion/lua-resty-openssl@fa45b6c)

Signed-off-by: Aapo Talvensaari <[email protected]>
bungle added a commit that referenced this issue May 10, 2023
### Summary

#### [0.8.22] - 2023-04-26
##### bug fixes
- **crypto:** use OPENSSL_free in BoringSSL ([#107](fffonion/lua-resty-openssl#107)) [7830212](fffonion/lua-resty-openssl@7830212)

<a name="0.8.21"></a>
#### [0.8.21] - 2023-03-24
##### features
- **x509.store:** extend verify to support setting flags ([#104](fffonion/lua-resty-openssl#104)) [fa45b6c](fffonion/lua-resty-openssl@fa45b6c)

Signed-off-by: Aapo Talvensaari <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants