Complete publication support#1795
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThis change set implements full CRUD and synchronization support for publications in both the CRDT and FWData APIs. It introduces new change types, validators, and synchronization helpers for publications, removes the obsolete Changes
Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes found. Possibly related PRs
Suggested reviewers
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
Bot
added
the
💻 FW Lite
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
rmunn
force-pushed
the
feat/complete-publication-support
branch
from
a0c221c to
08d4c7f
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
backend/FwLite/FwDataMiniLcmBridge/Api/UpdateProxy/UpdatePublicationProxy.cs (1)
7-25: Consider documenting the setter restriction.The proxy class follows the established pattern, but the
NotImplementedExceptionin theNamesetter might be confusing without context. Consider adding a comment explaining why direct setting is not supported or what the intended update mechanism is.public override MultiString Name { get => new UpdateMultiStringProxy(_lcmPublication.Name, _lexboxLcmApi); - set => throw new NotImplementedException(); + set => throw new NotImplementedException("Use the proxy's methods to update the publication name"); }backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs (1)
229-232: Consider improving error clarity for missing publicationsI noticed that
AddPublicationusesSingleAsync(pub => pub.Id == publicationId), which throws anInvalidOperationExceptionif no publication is found. This pattern is also used elsewhere inCrdtMiniLcmApi(e.g., lines 297 and 362 for complex form types), so it’s consistent across the codebase.If you’d like to provide more descriptive errors, you could:
- Switch to
SingleOrDefaultAsync(...)and throw a custom exception (e.g.PublicationNotFoundException) when the result isnull.- Or catch the
InvalidOperationExceptionand rethrow a clearer exception message.Otherwise, if the default exception is handled suitably at a higher level, no changes are strictly necessary.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
backend/FwLite/FwDataMiniLcmBridge/Api/FwDataMiniLcmApi.cs(1 hunks)backend/FwLite/FwDataMiniLcmBridge/Api/UpdateProxy/UpdateEntryProxy.cs(1 hunks)backend/FwLite/FwDataMiniLcmBridge/Api/UpdateProxy/UpdatePublicationProxy.cs(1 hunks)backend/FwLite/FwLiteProjectSync.Tests/SyncTests.cs(0 hunks)backend/FwLite/FwLiteProjectSync.Tests/UpdateDiffTests.cs(1 hunks)backend/FwLite/FwLiteProjectSync/CrdtFwdataProjectSyncService.cs(1 hunks)backend/FwLite/LcmCrdt.Tests/Changes/RegressionDeserializationData.json(1 hunks)backend/FwLite/LcmCrdt.Tests/Changes/UseChangesTests.cs(1 hunks)backend/FwLite/LcmCrdt.Tests/DataModelSnapshotTests.VerifyChangeModels.verified.txt(1 hunks)backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs(1 hunks)backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs(1 hunks)backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs(1 hunks)backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs(5 hunks)backend/FwLite/LcmCrdt/LcmCrdtKernel.cs(1 hunks)backend/FwLite/LcmCrdt/Objects/JsonPatchChangeExtractor.cs(1 hunks)backend/FwLite/MiniLcm.Tests/AutoFakerHelpers/EntryFakerHelper.cs(1 hunks)backend/FwLite/MiniLcm/Models/Publication.cs(0 hunks)backend/FwLite/MiniLcm/SyncHelpers/EntrySync.cs(3 hunks)backend/FwLite/MiniLcm/SyncHelpers/PublicationSync.cs(1 hunks)backend/FwLite/MiniLcm/Validators/MiniLcmValidators.cs(3 hunks)backend/FwLite/MiniLcm/Validators/PublicationValidator.cs(1 hunks)
💤 Files with no reviewable changes (2)
- backend/FwLite/MiniLcm/Models/Publication.cs
- backend/FwLite/FwLiteProjectSync.Tests/SyncTests.cs
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt.Tests/DataModelSnapshotTests.VerifyChangeModels.verified.txt (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1609
File: backend/FwLite/LcmCrdt/CompiledModels/ComplexFormComponentEntityType.cs:138-182
Timestamp: 2025-04-17T02:52:44.986Z
Learning: Files in the LcmCrdt.CompiledModels namespace contain auto-generated Entity Framework Core model code that should be ignored during code reviews since they shouldn't be manually modified.
backend/FwLite/LcmCrdt/LcmCrdtKernel.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt.Tests/Changes/UseChangesTests.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt/Objects/JsonPatchChangeExtractor.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/MiniLcm/SyncHelpers/EntrySync.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/MiniLcm/SyncHelpers/PublicationSync.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/FwDataMiniLcmBridge/Api/FwDataMiniLcmApi.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs (1)
Learnt from: hahn-kev
PR: sillsdev/languageforge-lexbox#1760
File: backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs:274-277
Timestamp: 2025-06-27T09:24:39.507Z
Learning: In the CrdtMiniLcmApi class, the user prefers to keep the current AddChanges method signature (IEnumerable<IChange>) rather than modifying it to support IAsyncEnumerable for streaming, even when it means materializing collections into memory for bulk operations.
🧬 Code Graph Analysis (5)
backend/FwLite/FwDataMiniLcmBridge/Api/UpdateProxy/UpdateEntryProxy.cs (2)
backend/FwLite/MiniLcm/Models/Publication.cs (1)
Publication(3-27)backend/FwLite/FwDataMiniLcmBridge/Api/FwDataMiniLcmApi.cs (1)
Publication(301-310)
backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs (3)
backend/FwLite/MiniLcm/Models/Publication.cs (2)
Guid(7-10)Publication(3-27)backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs (1)
ValueTask(10-14)backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs (1)
ValueTask(12-20)
backend/FwLite/FwLiteProjectSync/CrdtFwdataProjectSyncService.cs (1)
backend/FwLite/MiniLcm/SyncHelpers/PublicationSync.cs (1)
PublicationSync(6-61)
backend/FwLite/LcmCrdt/Objects/JsonPatchChangeExtractor.cs (3)
backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs (1)
AddPublicationChange(7-17)backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs (1)
RemovePublicationChange(7-15)backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs (1)
ReplacePublicationChange(7-21)
backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs (2)
backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs (1)
ValueTask(12-16)backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs (1)
ValueTask(12-20)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Analyze (csharp)
- GitHub Check: Build FW Lite and run tests
🔇 Additional comments (34)
backend/FwLite/FwDataMiniLcmBridge/Api/UpdateProxy/UpdateEntryProxy.cs (1)
66-70: LGTM! Property follows established pattern.The
PublishInproperty implementation is consistent with other collection properties in theUpdateEntryProxyclass, appropriately throwingNotImplementedExceptionfor both getter and setter as expected for this proxy pattern.backend/FwLite/LcmCrdt/LcmCrdtKernel.cs (1)
234-236: LGTM! Publication change types properly registered.The three new publication change types (
AddPublicationChange,RemovePublicationChange,ReplacePublicationChange) are correctly added to the CRDT kernel configuration and follow the established naming and placement patterns for entity change types.backend/FwLite/FwLiteProjectSync.Tests/UpdateDiffTests.cs (1)
23-28: LGTM! Test logic simplified appropriately.The removal of conditional logic for
PublishInexclusion correctly reflects that publications now have full CRDT support, eliminating the need for feature-flag-based conditional test logic.backend/FwLite/LcmCrdt.Tests/DataModelSnapshotTests.VerifyChangeModels.verified.txt (1)
127-138: LGTM! Test snapshot correctly updated.The snapshot file has been properly updated with the three new publication change types, maintaining consistency with the existing format and naming conventions for change type discriminators.
backend/FwLite/FwLiteProjectSync/CrdtFwdataProjectSyncService.cs (1)
75-77: LGTM! Publication sync implementation follows established pattern.The publication synchronization logic correctly follows the bidirectional sync pattern used for other entity types, ensuring consistency between CRDT and FWData APIs while properly accumulating change counts.
backend/FwLite/LcmCrdt.Tests/Changes/RegressionDeserializationData.json (1)
241-272: LGTM! Test data structure is consistent.The new publication-related change entries follow the established JSON structure pattern and provide comprehensive coverage for the three publication change types. The test data includes proper GUIDs, multilingual names, and all required fields.
backend/FwLite/MiniLcm/Validators/MiniLcmValidators.cs (3)
15-15: LGTM! Validator parameter addition follows established pattern.The
PublicationValidatorparameter is correctly added to the record constructor, maintaining consistency with other validator parameters.
53-57: LGTM! ValidateAndThrow method follows established pattern.The async
ValidateAndThrowmethod forPublicationmaintains consistency with the existing validation methods, properly delegating to thePublicationValidator.
76-76: LGTM! Service registration follows established pattern.The transient service registration for
IValidator<Publication>is consistent with other validator registrations in the extension method.backend/FwLite/LcmCrdt/Changes/Entries/AddPublicationChange.cs (2)
7-11: LGTM! Constructor and property implementation follows established patterns.The class properly inherits from
EditChange<Entry>, implementsISelfNamedType<AddPublicationChange>, and uses a clean constructor pattern with immutable property initialization.
12-17: LGTM! ApplyChange implementation includes proper deletion check.The method correctly checks if the publication is deleted before adding it to the entry's
PublishIncollection, which is good defensive programming practice. The async pattern is used appropriately.backend/FwLite/LcmCrdt.Tests/Changes/UseChangesTests.cs (2)
168-175: LGTM! Publication creation follows established test patterns.The test creates two distinct publications with proper IDs and names, providing good coverage for replacement scenarios. The naming ("Main" and "Second") is clear and descriptive.
176-183: LGTM! Publication change dependency chain is correctly established.The dependency relationships are properly defined:
AddPublicationChangedepends on publication creationReplacePublicationChangedepends on all prerequisite changesRemovePublicationChangedepends on the replacementThis ensures proper ordering and comprehensive testing of the publication change lifecycle.
backend/FwLite/LcmCrdt/Changes/Entries/ReplacePublicationChange.cs (1)
7-11: LGTM! Constructor and property implementation follows established patterns.The class properly inherits from
EditChange<Entry>, implementsISelfNamedType<ReplacePublicationChange>, and uses a clean constructor pattern with immutable properties for both the new publication and old publication ID.backend/FwLite/MiniLcm.Tests/AutoFakerHelpers/EntryFakerHelper.cs (2)
13-14: LGTM!The addition of the
createPublicationsparameter with a default value oftruemaintains backward compatibility while providing flexibility for test scenarios.
21-21: LGTM!The simplified logic directly calls
CreatePublicationswhen enabled, which is cleaner than the previous conditional check onPublication.SupportsCrdts. This aligns with the PR's objective to remove the SupportsCrdts flag.backend/FwLite/LcmCrdt/Objects/JsonPatchChangeExtractor.cs (1)
146-172: LGTM!The publication change handling follows the established pattern for other collections in the same method. The implementation correctly:
- Handles all three operation types (Add, Remove, Replace)
- Performs null checks for Add and Replace operations
- Defaults to existing publication for Remove operations when new value is null
- Provides clear error messages for unsupported operations
- Uses the appropriate change classes (AddPublicationChange, RemovePublicationChange, ReplacePublicationChange)
The code is consistent with the existing collection handling patterns in the file.
backend/FwLite/LcmCrdt/Changes/Entries/RemovePublicationChange.cs (1)
10-14: LGTM!The implementation is straightforward and follows the established pattern. The use of
Where().ToList()to filter out the publication by ID is correct and consistent with theReplacePublicationChangeclass shown in the relevant code snippets.Note: Unlike
AddPublicationChangewhich checkscontext.IsObjectDeleted(), this class doesn't perform context checks, which is appropriate since we're removing the publication regardless of its state.backend/FwLite/MiniLcm/Validators/PublicationValidator.cs (1)
11-12: LGTM!The validation rules are appropriate:
- Ensuring
DeletedAtis null prevents validation of soft-deleted publications- Using
NoEmptyValuesensures the publication name contains meaningful contentbackend/FwLite/MiniLcm/SyncHelpers/EntrySync.cs (3)
27-27: LGTM! Consistent integration pattern.The addition of publication synchronization follows the established pattern used for other entry components like senses and complex form types.
36-45: LGTM! Follows established synchronization pattern.The
SyncPublicationsmethod correctly implements the same diff-based synchronization pattern used throughout the class for other collections.
144-162: LGTM! Consistent implementation with other diff APIs.The
PublicationsDiffApiclass follows the exact same pattern asComplexFormTypesDiffApi, with proper async/await usage and consistent return values. TheReplacemethod correctly returns 0 since publications don't have mutable properties beyond the name, which is handled via the update API.backend/FwLite/FwDataMiniLcmBridge/Api/FwDataMiniLcmApi.cs (2)
314-325: LGTM! Follows established update pattern.The implementation correctly follows the same pattern as other update methods in the class:
- Retrieves the LCM publication with proper null checking
- Uses UndoableUnitOfWorkHelper for transactional consistency
- Applies updates via UpdatePublicationProxy
- Returns the updated publication object
327-331: LGTM! Consistent async update implementation.The method correctly implements the before/after update pattern using
PublicationSync.Syncwithin an async unit of work, consistent with other similar methods in the class. The error handling for missing publications is appropriate.backend/FwLite/MiniLcm/SyncHelpers/PublicationSync.cs (4)
6-16: LGTM! Well-designed sync utility following established patterns.The
PublicationSyncclass correctly implements the standard synchronization pattern used throughout the codebase, with array-based sync usingDiffCollection.Diffand a custom diff API implementation.
18-27: LGTM! Efficient individual publication sync implementation.The single publication sync method correctly:
- Uses patch-based updates for efficiency
- Only performs API calls when changes exist
- Returns appropriate change counts
- Follows the established async pattern
29-40: LGTM! Appropriate focus on Name property for publications.The
DiffToUpdatemethod correctly focuses only on theNameproperty usingMultiStringDiff, which is appropriate since publications are simple entities with just an ID and multilingual name. The patch document generation follows the established pattern.
42-60: LGTM! Consistent diff API implementation.The
PublicationsDiffApiclass correctly implements the required interface methods:
AddandRemovemethods properly use the API and return change countsReplacemethod delegates to the single publication sync method- All methods follow async/await patterns consistently
backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs (6)
192-200: LGTM: Method relocation is cleanThe
GetPublications()andGetPublication(Guid id)methods have been moved within the class without any implementation changes. The relocation improves code organization by grouping publication-related methods together.
217-222: LGTM: Proper async implementation with validationThe
UpdatePublicationmethod has been correctly converted from a stub to a fully async implementation. The implementation follows the established pattern used by other similar methods in the class, usingPublicationSync.Syncfor synchronization and proper error handling.
234-237: LGTM: Simple and correct implementationThe
RemovePublicationmethod correctly creates aRemovePublicationChangewith the provided IDs. The implementation is straightforward and follows the expected pattern.
543-546: LGTM: Consistent with existing patternsThe addition of publication handling in
CreateEntryChangesfollows the same pattern as complex form types and maintains consistency with the method's existing logic.
577-577: LGTM: Proper integration with entry creationThe integration of publication changes into the
CreateEntrymethod is clean and consistent with how other related collections are handled.
644-660: LGTM: Thorough validation with proper error handlingThe
ToPublicationslocal method implements comprehensive validation:
- Checks for default (empty) publication IDs
- Verifies publication existence in the database
- Provides clear error messages for invalid operations
The implementation mirrors the validation pattern used in
ToComplexFormTypes, ensuring consistency across the codebase.
The code was already there, this commit just moves it around so it's next to the other publication-related methods, to find it easier.
rmunn
force-pushed
the
feat/complete-publication-support
branch
from
0feff68 to
eaf2db9
Compare
|
Rebased on top of current develop to fix the (very minor) merge conflict in UseChangesTests.cs. |
The merge algorithm naturally couldn't know that you now have to use repoFactory and that the Publications property is now on the repo.
rmunn
left a comment
rmunn
left a comment
There was a problem hiding this comment.
Self-review completed, found just one place where the code might be improvable. Kevin, what do you think?
Weird; my self-review comment didn't get added. Maybe I forgot to click the submit button on the comment? Anyway, it was in reference to the ReplacePublicationChange code being maybe a bit too complex for the tiny performance benefit that that complexity would carry, and wondering if I should model it more after the way the ReplaceComplexFormTypeChange code works. And I just decided that yes, I should. Commit incoming, at which point my self-review comment that got lost would have become redundant anyway. |
This was removed before, but the git merge added it back in.
The comment that got lost was asking if I should make the change that I ended up making in commit 27d755b. |
hahn-kev
left a comment
hahn-kev
left a comment
There was a problem hiding this comment.
looks good to me, just a couple minor changes.
One odd thing I noticed is that github thinks backend/FwLite/LcmCrdt.Tests/MiniLcmTests/PublicationsTests.cs is a binary file in the Files changed tab. Maybe check there's nothing weird going on with it, encoding, bom etc.
I copied that file from another one (don't remember which now) and didn't notice that it was encoded in UTF-16LE for some reason. Maybe Jason created the file I copied from in Visual Studio, and Visual Studio still doesn't default to UTF-8? At any rate, the encoding of that file is now UTF-8 (with no BOM). Incidentally, Kevin, your Rider config seems to be set up to create UTF-8 files with a BOM, which is mildly annoying when I try to work with them on Linux. The BOM is almost always invisible, but it shows up (at least for me) in Anyway, that file is fixed now. |
…ication-support Fixes merge conflict in backend/FwLite/LcmCrdt/CrdtMiniLcmApi.cs
|
Running tests again to make sure the merge from |
3 participants
Fixes #1491.
I can't take credit for the "implement querying publications in crdt implementation" one, because that code was already there (written by Jason) before I started this PR; I simply moved it to be closer to the other publication-related API methods so it wouldn't be so easy to overlook.