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

Support for Partial Updates #21

Open
elersong opened this issue Jul 13, 2024 · 0 comments
Open

Support for Partial Updates #21

elersong opened this issue Jul 13, 2024 · 0 comments
Labels
from_willyovale An issue described in original project, but never implemented planning Not yet ready for development

Comments

@elersong
Copy link
Owner

Description

Fireorm currently requires fetching a complete document, updating it, and then passing it to the update() function for any changes. This approach can lead to performance issues and potential data consistency problems when different fields of the same document are being updated concurrently. Implementing partial updates, similar to Firestore's native capabilities, would resolve these issues.

Steps to Reproduce

  1. Create a model with multiple fields.
  2. Attempt to update a single field of a document using Fireorm without fetching the entire document first.
  3. Notice that the current implementation does not support partial updates.

Expected Behavior

Ability to update specific fields of a document without fetching the entire document, using a configuration to specify the update strategy.

Actual Behavior

Currently, the entire document must be fetched, updated, and then saved, leading to potential performance and data consistency issues.

Acceptance Criteria

  • Implement support for partial updates in Fireorm.
  • Add a flag at initialization (updateStrategy: 'replace' | 'merge') with replace as the default.
  • Allow the repository update method to accept a configuration object as a second parameter to locally override the global setting.

Additional Context

  • July 8, 2020: Initial issue raised about the limitation of requiring complete objects for updates.
  • January 21, 2021: Comment on the potential data consistency issues when updating different fields concurrently.
  • February 20, 2021: Proposed implementation strategy to add a flag for update strategy and allow local overrides.

Proposed API Changes

  1. Global Update Strategy Configuration:

    • Introduce a global configuration option during Fireorm initialization to set the default update strategy.
    initialize({ updateStrategy: 'merge' });
  2. Local Override for Update Method:

    • Allow the update method to accept a second parameter for configuration, enabling local override of the update strategy.
    // Default update strategy (e.g., 'replace')
    repo.update({ id: userId, display_name: "new display name" });
    
    // Override update strategy locally to 'merge'
    repo.update({ id: userId, display_name: "new display name" }, { strategy: 'merge' });
  3. Implementation Details:

    • Modify the update method in the repository to handle partial updates based on the configured strategy.
    • Ensure backward compatibility by defaulting to the replace strategy.
    • Provide thorough testing to validate the new functionality and ensure it does not introduce any regressions.

Example Implementation

@Collection()
class UserPublicModel {
  id: string;
  display_name: string;
  username: string;
}

// Initialize Fireorm with global update strategy
initialize({ updateStrategy: 'merge' });

// Repository instance
const repo = getBaseRepository(UserPublicModel);

// Partial update using default strategy
repo.update({ id: userId, display_name: "new display name" });

// Partial update with local override
repo.update({ id: userId, display_name: "new display name" }, { strategy: 'merge' });

Original Issue

@elersong elersong added from_willyovale An issue described in original project, but never implemented planning Not yet ready for development labels Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
from_willyovale An issue described in original project, but never implemented planning Not yet ready for development
Projects
None yet
Development

No branches or pull requests

1 participant