Comment for #1642

arilloid commented on Nov 05, 2024

Hello @monikakuster ,

I previously had to unassign myself from the related issue due to some personal circumstances, but I now have more time and resources to tackle adding new actions to the Baserow component. Could you please assign me to this issue? I’m ready to get started and see it through this time.

Thank you!

View on GitHub

Baserow - Delete Row action #1642

monikakuster posted on Oct 22, 2024

Implement the Delete Row action for the Baserow component to enable users to remove specific rows from a table within their Baserow database.

Action properties:

• table id - id of the table from which the row should be deleted
• row id - id of the row that needs to be deleted

Ouput:

• no output

Documentation Reference: https://baserow.io/api-docs

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/bytechefhq/bytechef/issues/1642">View on GitHub</a></div>

Contribution Process

Dev Environment Setup

During my first attempt, I struggled to get the project running, even though I closely followed the instructions in the CONTRIBUTING.md (or at least I thought I did), which left me unable to test my draft code. This time, I decided to focus on correctly setting up my development environment from the very beginning.

Here is an overview of the entire setup process, combining the problems I faced during both my initial and current attempts:

The first issue I encountered was an error when cloning the repository: "File name too long" / "Clone succeeded but checkout failed." I resolved this by configuring Git to accept long paths.

Next, I downloaded the compatible version of the Java SDK (21+) and the Java support extension for VS Code. I then started the necessary Docker containers for the dependent infrastructure (Redis, PostgreSQL, and Mailhog). After compiling the codebase, I attempted to start the server but encountered an error with a terrifyingly long stack trace. I thought the issue was related to unresolved dependencies, as, at first glance, the error message seemed to point in that direction. So, I checked the prerequisites and tried rebuilding the project, but the problem persisted. Upon further investigation (of the stack trace that was too long for the LLM to process), I discovered that the issue was related to the server's inability to connect to PostgreSQL. I checked the PostgreSQL Docker container's logs, but everything appeared to be running as expected. Confused, I decided to seek help on the project's Discord. One of the maintainers asked if I was trying to access an external database, and that’s when the realization struck me: something else was likely occupying the port where the PostgreSQL container was supposed to run. Sure enough, I found that my local PostgreSQL server server was already using that port. After terminating the process and restarting the Docker containers, the server started up as expected.

With the development environment finally set up, I was ready to move forward with implementing a feature.

Feature Implementation

As a Java noob, I was intimidated by the project, especially since I had no experience with Gradle or Java Spring Boot.

On my first attempt, I started by locating where the component actions needed to be implemented. Although I found the relevant functions, I quickly realized that this approach wasn't ideal. Without a clear understanding of the project setup, I struggled to make sense of imported custom classes, methods, and constants, and, inevitably, got overwhelmed.

On my second attempt, I took a step back to study the project structure and familiarize myself with the tools used. I also revisited the project's history to see how similar features had been implemented, which helped me understand the workflow. (By this point, more component actions had been implemented, so I had a chance to learn by looking at previous PRs + the docs on adding new components/component actions were updated, making the implementation process clear).

Lesson learned: It's much easier to tune into a project that is further along in its development, as there's more work to reference and learn from.

After studying the project, I began coding by following the instructions in the ByteChef Developer Guide and referencing existing actions for guidance.

I discovered that creating an action starts with the action() method from the ComponentDsl package. It initializes an instance of ModifiableActionDefinition which provides various methods, such as title(), description(), properties(), and perform(), to define the action’s properties and logic. Once all the properties are defined, the action is registered in the component handler, making it available for use.

For the action I was implementing, no output was required. Its sole purpose was to send an HTTP DELETE request to a specific API endpoint, using a table ID and a row ID as inputs. I constructed the URL for this request by referring to the Baserow documentation (you need to create an account to see the docs!). To execute the request, I utilized the http() method provided by the ActionContext class.

Overall, the project already provided all the necessary building blocks. My main task was to understand how these components worked together and supply the required parameters to define the action correctly. Once I understood the structure and flow, implementing the action became a straightforward and logical process.

BaserowDeleteRowAction.java:

package com.bytechef.component.baserow.action;

import static com.bytechef.component.baserow.constant.BaserowConstants.ROW_ID;
import static com.bytechef.component.baserow.constant.BaserowConstants.TABLE_ID;
import static com.bytechef.component.definition.ComponentDsl.action;
import static com.bytechef.component.definition.ComponentDsl.integer;

import com.bytechef.component.definition.ActionContext;
import com.bytechef.component.definition.ComponentDsl.ModifiableActionDefinition;
import com.bytechef.component.definition.Parameters;

/**
 * @author Arina Kolodeznikova
 */
public class BaserowDeleteRowAction {

    public static final ModifiableActionDefinition ACTION_DEFINITION = action("deleteRow")
        .title("Delete Row")
        .description("Deletes the specified row.")
        .properties(
            integer(TABLE_ID)
                .label("Table ID")
                .description("ID of the table containing the row to be deleted.")
                .required(true),
            integer(ROW_ID)
                .label("Row ID")
                .description("ID of the row to be deleted.")
                .required(true))
        .perform(BaserowDeleteRowAction::perform);

    private BaserowDeleteRowAction() {
    }

    protected static Object perform(
        Parameters inputParameters, Parameters connectionParameters, ActionContext actionContext) {

        actionContext
            .http(http -> http.delete(
                "/database/rows/table/" + inputParameters.getRequiredString(TABLE_ID) + "/" +
                    inputParameters.getRequiredString(ROW_ID) + "/"))
            .execute();

        return null;
    }
}

Testing

After implementing the action, I tested the row deletion by rebuilding the project, starting the server and client, creating a test table in my Baserow account, setting up the test workflow in the frontend, adding the delete row action for the Baserow component, connecting the component to the service using my Baserow credentials, inputting the table and row IDs, and executing the workflow — and it worked as expected! (For details on creating and testing components, refer to ByteChef's Quick Start Guide).

Creating the Delete Row action:

Workflow successfully running:

The row I specified (row #1) is no longer in the DB:

After confirming that my action worked as expected, I began working on the unit test. I reviewed tests for other Baserow actions and found that they were fairly simple, involving the use of JUnit and Mockito for mocking API interactions and input parameters to ensure the correct API calls were made and expected results returned.

Following this approach, I mocked the ActionContext, Http.Executor, and Http.Response to simulate the API. Using MockParametersFactory, I created mock parameters for the table and row IDs. I then configured the Http.Executor to return the mocked response and tested the perform() method, confirming it returned null as expected for a successful row deletion. (See my unit test here).

After several iterations of formatting the code, running tests, and fixing minor issues, all tests passed, and my changes were ready for a PR. I went ahead and submitted a Pull Request, and it was merged the following day!

1642 - baserow delete row action #1743

arilloid posted on Nov 15, 2024

Description

Implemented the Delete Row action for the Baserow component to enable users to remove specific rows from a table within their Baserow database.

Fixes #1642

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Added a new unit test and executed it alongside the existing test in the module to ensure all tests pass successfully.

• Manually tested the action by creating and executing a test workflow on the client side.

Created a test workflow that included a Baserow delete row action. Configured the workflow by adding the authentication token to connections and specifying the table ID and row ID for the testing Baserow table:

Executed the workflow:

Checked the specified Baserow database table to confirm that the specified row was successfully deleted.:

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
  • Referenced the code for other Baserow component actions
• [ ] I have made corresponding changes to the documentation
  • Running gradlew generateDocumentation for the module did not produce any documentation updates
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

View on GitHub

The 2-nd issue I worked on

After my first PR was merged, I was curious to implement an action for another component to explore how the backend integrates interactions with other services. I checked the open issues and found one related to adding an action for the Google Drive component.

Google Drive - Get File action #1647

monikakuster posted on Oct 24, 2024

The Get File action for the Google Drive component is designed to retrieve a specified file from the user's Google Drive. This action allows users to access file metadata and content.

Action properties:

• file ID - the ID of the file you wish to retrieve

Ouput:

• file - a file object containing detailed information about the retrieved file.

Documentation Reference: https://developers.google.com/drive/api/reference/rest/v3/files/get

View on GitHub

I left a comment asking to be assigned the issue and also requesting feedback on possible areas for improvement in my previous PR.

Although I didn't receive any feedback, the issue was assigned to me a couple of days later. At first, I was a bit surprised by the delay in responses (mainly because the maintainers had been super quick to reply and assign issues before), but after a quick Google search, I learned that there was a long weekend in Croatia, where most of the project maintainers are based.

Note: The ability to put yourself in someone else's shoes is especially important when working with people from all around the world. As for me, I certainly wouldn't want to be bothered during the holidays.

Contribution Process

Implementing the feature

I was already familiar with the project, so writing the second feature was much easier. The main difference between writing the action for Baserow and Google Drive was that it used different custom classes. So, this time, I essentially needed to familiarize myself with a few new "building blocks", the key one being the Google API SDK library for Java.

I read the documentation reference linked by the maintainer and realized that I saw the same method in the Google Drive Copy File action. By extracting the necessary components from the existing logic, I was able to write an action that returns the metadata for the selected file in the linked Google Drive (See the code on GitHub).

Testing the feature

Manually testing the feature was fun, as I got to set up a Google Cloud account and OAuth2 credentials to access my Google Drive from the frontend application. (I followed the instructions for the Google Drive component in the docs to generate the necessary credentials).

Retrieving the metadata for one of my Google Drive documents:

After manually testing the feature in the frontend, I created a unit test in the same way as before, using JUnit and Mockito (GoogleDriveGetFileActionTest.java).

Then, I ran the code formatter, ensured that my code passed all the checks, and submitted a Pull Request, asking a few questions about the expected output in the comments. (However, as of writing this blog post, the maintainers haven’t yet responded).

1647 - Added Google Drive Get File Action #1753

arilloid posted on Nov 19, 2024

Description

Added Get File action to the Google Drive component.

Fixes #1647

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

• Added a new unit test and executed it alongside the existing test in the module to ensure all tests pass successfully.
• Manually tested the action by creating and executing a test workflow on the client side.

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
  • Referenced the code for other Google Drive component actions
• [ ] I have made corresponding changes to the documentation
  • Running gradlew generateDocumentation for the module did not produce any documentation updates
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

View on GitHub

Afterthoughts

Contributing to ByteChef was a valuable learning experience. I got to author new features and unit tests, learned the importance of taking time to understand the project structure and leveraging existing code as a reference for implementing new features. + I gained hands-on experience with new tools and libraries, including Gradle, Baserow, the Google Drive API SDK, JUnit, and Mockito.