yujunjun/OpenMetadata
1
0
Fork 0
mirror of https://github.com/open-metadata/OpenMetadata.git synced 2026-01-06 12:36:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

updated-fqdn-to-fqn-in-docs (#7342)

Browse Source
This commit is contained in:
Abhishek Pandey 2022-09-08 18:58:39 +05:30 committed by GitHub
parent d486e95b69
commit 2846385eeb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
openmetadata-docs/content/main-concepts/high-level-design.md
View File

@ -76,7 +76,7 @@ in a simple language (REST), without the learning curve of diving into specific
When we interact with most of our Entities, we follow the same endpoint structure. For example:
- `GET <url>/api/v1/<collectionName>/<id>` to retrieve an Entity instance by ID, or
- `GET <url>/api/v1/<collectionName>/name/<FQDN>` to query by its fully qualified domain name.
- `GET <url>/api/v1/<collectionName>/name/<FQN>` to query by its fully qualified domain name.
Similarly, we support other CRUD operations, each of them expecting a specific incoming data structure, and returning
the Entity's class. As the foundations of OpenMetadata are the Entities definitions, we have this data contract with
@ -102,7 +102,7 @@ As there are processes repeated across all Entities (e.g., listing entities in a
version from an Entity), the Entity Repository extends an **Interface** that implements some basic functionalities and
abstracts Entity specific logic.
Each Entity then needs to implement its **server-side processes** such as building the FQDN based on the Entity hierarchy,
Each Entity then needs to implement its **server-side processes** such as building the FQN based on the Entity hierarchy,
how the Entity stores and retrieves **Relationship** information with other Entities or how the Entity reacts to **Change Events**.
## Entity Storage Layer
@ -218,7 +218,7 @@ The first steps are fairly similar:
3. We validate the Entity and cook some attributes during the prepare step.
After processing and validating the Entity request, we then check if the Entity instance has already been stored,
querying the backend database by its FQDN. If it has not, then we proceed with the same logic as the `POST`
querying the backend database by its FQN. If it has not, then we proceed with the same logic as the `POST`
operation -> simple creation. Otherwise, we need to validate the updated fields.
#### Set Fields

10
openmetadata-docs/content/sdk/python/index.md
View File

@ -274,10 +274,10 @@ Repeating the exercise and reviewing the required fields to instantiate an `Enti
The `id` we actually saw it by printing the `service_entity` JSON. However, let's imagine that it did not happen, and the only information we have from the `DatabaseService` is its name.
To retrieve the `id`, we should then ask the `metadata` to find our Entity by its FQDN:
To retrieve the `id`, we should then ask the `metadata` to find our Entity by its FQN:
```json
service_query = metadata.get_by_name(entity=DatabaseService, fqdn="test-service-table")
service_query = metadata.get_by_name(entity=DatabaseService, fqn="test-service-table")
```
We have just used the `get_by_name` method. This method is the same that we will use for any Entity. This is why as an argument, we need to provide the `entity` field. Again, instead of relying on error-prone handwritten parameters, we can just pass the `pydantic` model we expect to get back. In our case, a `DatabaseService`.
@ -370,10 +370,10 @@ print(updated_table_entity.owner)
# EntityReference(id=Uuid(__root__=UUID('48793f0c-5308-45c1-9bf4-06a82c8d7bf9')), type='user', name='random-user', description=None, displayName=None, href=Href(__root__=AnyUrl('http://localhost:8585/api/v1/users/48793f0c-5308-45c1-9bf4-06a82c8d7bf9', scheme='http', host='localhost', host_type='int_domain', port='8585', path='/api/v1/users/48793f0c-5308-45c1-9bf4-06a82c8d7bf9')))
```
If we did not save the `updated_table_entity` variable and we should need to query it to review the `owner` field, we can run the `get_by_name` using the proper FQDN definition for `Table`s:
If we did not save the `updated_table_entity` variable and we should need to query it to review the `owner` field, we can run the `get_by_name` using the proper FQN definition for `Table`s:
```python
my_table = metadata.get_by_name(entity=Table, fqdn="test-service-table.test-db.test-schema.test")7. Delete the Table
my_table = metadata.get_by_name(entity=Table, fqn="test-service-table.test-db.test-schema.test")7. Delete the Table
```
<Note>
@ -394,7 +394,7 @@ We could directly clean up the service itself with a Hard and Recursive delete.
```python
service_id = metadata.get_by_name(
entity=DatabaseService, fqdn="test-service-table"
entity=DatabaseService, fqn="test-service-table"
).id
metadata.delete(