Comprehensive Usage Examples

Data Model Design

To implement blog website functionality, the following data models need to be designed:

• Blog table: Used to save blog articles, including fields like title, content, author, published_status, show_at, like_count, etc. One account can publish multiple articles, so the account table and post table have a one-to-many relationship, connected through the author field.
• notification table: Used to save notifications, including fields like sender_account, receiver_account, message, etc. The account table establishes two one-to-many relationships with the notification table through the sender_account and receiver_account fields, representing sender and receiver respectively. Overall, the account table and notification table have a many-to-many relationship. For more information about relationships, please refer to Data Model - Relationships.

Creating Data - Publishing a New Article

When users want to create a new article, we need to store the user input content in the database.

1. Page Design: Create a “Writing” page that includes components like title input and rich text editor for the main content.
2. Action Configuration: Configure an “Insert Blog” action on the “Add” button.
3. Data Mapping: Map the values of input components one by one to corresponding fields in the Blog data table (title, content, etc.). The author field is bound to the Logged in user’s id.

Reading Data - Displaying Article List

When performing data operations, filtering, sorting, and deduplication are often needed:

• Filter: Set one or more conditions to filter required data. For example, to get only published blogs, set condition: published_status = true.
• Sort: Define the display order of data. For example, sort by show_at field in descending order to put latest articles first. If the field has vector storage enabled, advanced semantic relevance sorting can also be implemented.
• Distinct: When non-duplicate data is needed, specify one or more fields to ensure uniqueness of returned results. For example, remove data with duplicate title fields.
• Limit: Control the number of returned records. 1 means getting a single record, greater than 1 gets an array.

In the blog website project, continue with the following operations:

1. Bind Data Source: Add a “List” component to the homepage and set its data source to the Blog table.
2. Configure Query: Using the query configuration mentioned above, add filter condition published_status = true to get only published articles; set sorting by show_at in descending order to put latest articles first.
3. Render List: Bind list item components like title and cover image to the current item data (item) fields such as title and cover_image.

Data Reading - Viewing Single Article Details

Demonstrates the collaborative work of data transmission and data usage.

1. Declare Parameter: Create a “Detail Page” and declare a path parameter: blog_id.
2. Set Parameter: Configure “Navigation” action on each list item in the article list. During navigation, assign the current item data’s id to blog_id, passing it to the “Detail Page”.
3. Use Parameter: Add a data source in the “Detail Page” and set a key filter condition: id equals the path parameter post_id. Also set data limit to 1.
4. Display Content: Through this precise query, the detail page can display all content of the specific article.

Updating Data - Liking and Sending Notifications

This step demonstrates how to modify existing data and execute a series of automated operations.

1. Configure Like Action: Configure an “Update Blog” action on the “Like” button.
   • Specify Target: Set filter condition to id equals current item data’s id, this is a crucial step to ensure only the correct record is updated.
   • Execute Update: Update the like_count field value to like_count + 1.
2. Chain Operation: Send Notification: After the like action succeeds, immediately add a second action - “Insert notification”, writing a new data entry to the notification table.
3. Use Context Data: The notification content can be dynamically generated, for example, sender sender_account is the logged in user’s ID, receiver receiver_account is the current item data’s author, and message content message is generated by concatenating content from the previous step’s result data.