-
Notifications
You must be signed in to change notification settings - Fork 13
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
fix: bad name on shared types #955
Conversation
📝 WalkthroughWalkthroughThis pull request encompasses a comprehensive set of changes across multiple files in the project, focusing on type system refinements, naming conventions, and version updates. The modifications span various programming languages and modules, including Rust, TypeScript, and Python. The changes primarily involve renaming type aliases, updating function signatures, and standardizing scalar types across different components of the system. A notable version update from "0.5.0-rc.8" to "0.5.0-rc.9" is consistent across multiple files. Changes
Sequence DiagramsequenceDiagram
participant NamingProcessor
participant VisitCollector
participant TypeRefCount
NamingProcessor->>TypeRefCount: Initialize reference counters
TypeRefCount->>TypeRefCount: Collect reference information
NamingProcessor->>VisitCollector: Create collector with reference counts
VisitCollector->>NamingProcessor: Generate names based on reference counts
The sequence diagram illustrates the enhanced naming process, showing how reference counting is used to inform name generation for types, with the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/typegraph/core/src/utils/postprocess/naming.rs (1)
306-322
: Optimize naming logic ingen_name
to prevent excessively long names.The
gen_name
function builds type names based on the path and type, which might result in long and unwieldy names for deeply nested structures. Consider simplifying the naming convention or limiting the depth of recursion to improve readability and maintainability of the generated names.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/typegraph/core/src/utils/postprocess/naming.rs
(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: test-full
- GitHub Check: lint-compat (macos-14, aarch64-apple-darwin, false)
- GitHub Check: lint-compat (macos-13, x86_64-apple-darwin, false)
- GitHub Check: pre-commit
🔇 Additional comments (4)
src/typegraph/core/src/utils/postprocess/naming.rs (4)
13-13
: Appropriate use ofIndexSet
for tracking referers.The introduction of
IndexSet
from theindexmap
crate is suitable for maintaining a set of referers with insertion order preserved, which can be beneficial for consistent naming.
37-48
: Correct initialization and usage of reference counters.The creation of
ref_counters
and the population of reference information usingcollect_ref_info
are properly implemented. Transferring the counts toVisitCollector
ensures accurate tracking of type references.
83-91
: Efficient implementation ofTypeRefCount::new_hit
.The
new_hit
method effectively updates thecounts
HashMap by inserting new referers or modifying existing entries. UsingIndexSet
ensures that referers are unique and order is maintained.
94-101
: Effective check inhas_more_than_one_referer
.The method
has_more_than_one_referer
accurately determines if a type has multiple referers by checking the length of the referer set. This is crucial for the naming logic that depends on the number of referers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/typegraph/core/src/utils/postprocess/naming.rs (1)
258-316
: Consider simplifying cycle handling based on type system constraints.According to the domain knowledge, cyclic types can only occur with user-renamed types, which are skipped by the naming processor. This means the cycle detection using
visited
set might be unnecessary.You could simplify the function by removing the cycle detection:
-fn collect_ref_info( - cx: &VisitContext, - acc: &mut TypeRefCount, - id: u32, - visited: &mut HashSet<u32>, -) -> anyhow::Result<()> { - if !visited.insert(id) { - return Ok(()); - } +fn collect_ref_info( + cx: &VisitContext, + acc: &mut TypeRefCount, + id: u32, +) -> anyhow::Result<()> { + if cx.user_named.contains(&id) { + return Ok(()); + } let node = &cx.tg.types[id as usize]; match node { // ... existing match arms with updated recursive calls ... }; - visited.remove(&id); Ok(()) }This would make the code simpler while maintaining correctness, as the type system's constraints naturally prevent cycles.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/typegraph/core/src/utils/postprocess/naming.rs
(5 hunks)
🧰 Additional context used
📓 Learnings (1)
src/typegraph/core/src/utils/postprocess/naming.rs (1)
Learnt from: michael-0acf4
PR: metatypedev/metatype#955
File: src/typegraph/core/src/utils/postprocess/naming.rs:258-305
Timestamp: 2025-01-07T20:11:43.287Z
Learning: In the Metatype codebase's type system (src/typegraph/core/src/utils/postprocess/naming.rs), cyclic types can only occur with user-renamed types, as a reference can only exist after a rename happens. These cycles are naturally handled because the naming post-processor skips processing of user-renamed types.
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: lint-compat (macos-14, aarch64-apple-darwin, false)
- GitHub Check: lint-compat (macos-13, x86_64-apple-darwin, false)
- GitHub Check: test-full
- GitHub Check: pre-commit
🔇 Additional comments (5)
src/typegraph/core/src/utils/postprocess/naming.rs (5)
13-13
: LGTM! Well-designed data structures for reference tracking.The choice of
IndexSet
and the addition of reference counting structures are well-thought-out. TheIndexSet
provides efficient operations while maintaining insertion order, which is beneficial for consistent type naming.Also applies to: 74-74, 78-80
36-48
: LGTM! Good separation of concerns in the postprocessing logic.The two-phase approach (collecting references before name generation) is well-structured and maintains clear separation of concerns.
82-91
: LGTM! Clean and efficient reference counting implementation.The
new_hit
method makes good use of the Entry API for atomic operations, handling both new and existing entries efficiently.
93-101
: LGTM! Clear and safe implementation of reference checking.The
has_more_than_one_referrer
method is well-named and safely handles the case when a type has no referrers.
325-332
: LGTM! Clear strategy for handling shared type names.The implementation elegantly handles shared types by using a different naming scheme when a type has multiple referrers, preventing confusion that could arise from path-based naming.
Also applies to: 343-345
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tests/metagen/typegraphs/sample/rs/client.rs (1)
236-237
: Clarify the naming ofScalarStructShared2Partial
The struct
ScalarStructShared2Partial
is used as an argument type in several functions but has a name that may not clearly convey its purpose. Renaming it to something more descriptive, likeIdArgsPartial
orCommonArgsPartial
, could improve code clarity and maintainability.Also applies to: 430-475
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (11)
src/typegraph/core/src/snapshots/typegraph_core__tests__successful_serialization.snap
is excluded by!**/*.snap
tests/e2e/typegraph/__snapshots__/typegraph_test.ts.snap
is excluded by!**/*.snap
tests/metagen/__snapshots__/metagen_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/graphql/__snapshots__/graphql_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/grpc/__snapshots__/grpc_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/kv/__snapshots__/kv_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/s3/__snapshots__/s3_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/temporal/__snapshots__/temporal_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/typegate/__snapshots__/typegate_prisma_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/typegate/__snapshots__/typegate_runtime_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/wasm_reflected/rust/Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (14)
examples/typegraphs/metagen/rs/fdk.rs
(2 hunks)src/typegate/src/typegraphs/introspection.json
(3 hunks)src/typegate/src/typegraphs/typegate.json
(13 hunks)src/typegraph/core/src/utils/postprocess/naming.rs
(5 hunks)tests/metagen/typegraphs/identities/rs/fdk.rs
(4 hunks)tests/metagen/typegraphs/identities/ts/fdk.ts
(3 hunks)tests/metagen/typegraphs/sample/py/client.py
(16 hunks)tests/metagen/typegraphs/sample/py_upload/client.py
(3 hunks)tests/metagen/typegraphs/sample/rs/client.rs
(14 hunks)tests/metagen/typegraphs/sample/rs/main.rs
(4 hunks)tests/metagen/typegraphs/sample/rs_upload/client.rs
(6 hunks)tests/metagen/typegraphs/sample/ts/client.ts
(8 hunks)tests/metagen/typegraphs/sample/ts_upload/client.ts
(3 hunks)tests/runtimes/wasm_wire/rust/fdk.rs
(3 hunks)
👮 Files not reviewed due to content moderation or server errors (4)
- tests/metagen/typegraphs/sample/ts_upload/client.ts
- tests/metagen/typegraphs/sample/py_upload/client.py
- tests/metagen/typegraphs/sample/ts/client.ts
- tests/metagen/typegraphs/sample/py/client.py
🧰 Additional context used
📓 Learnings (1)
src/typegraph/core/src/utils/postprocess/naming.rs (1)
Learnt from: michael-0acf4
PR: metatypedev/metatype#955
File: src/typegraph/core/src/utils/postprocess/naming.rs:258-305
Timestamp: 2025-01-07T20:11:43.287Z
Learning: In the Metatype codebase's type system (src/typegraph/core/src/utils/postprocess/naming.rs), cyclic types can only occur with user-renamed types, as a reference can only exist after a rename happens. These cycles are naturally handled because the naming post-processor skips processing of user-renamed types.
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: lint-compat (macos-14, aarch64-apple-darwin, false)
- GitHub Check: lint-compat (macos-13, x86_64-apple-darwin, false)
- GitHub Check: bulid-docker (linux/amd64, custom-ubuntu-large)
- GitHub Check: test-full
- GitHub Check: pre-commit
🔇 Additional comments (34)
tests/metagen/typegraphs/sample/rs_upload/client.rs (4)
45-48
: Updated argument types forRootUploadFn
improve consistencyThe argument types for
RootUploadFn
have been updated to useScalarFileShared1
andRootUploadFnInputPathScalarString1Optional
, enhancing naming consistency and better reflecting shared scalar types.
65-69
: Consistent use of scalar types inRootUploadManyFn
The argument types for
RootUploadManyFn
have been updated toRootUploadManyFnInputPrefixScalarString1Optional
andRootUploadManyFnInputFilesScalarFileShared1List
, improving consistency across the codebase by standardizing the naming convention of shared scalar types.
84-99
: Addition of scalar type definitions enhances clarityThe introduction of scalar type definitions such as
ScalarFileShared1
,ScalarString1
, andScalarBoolean1
provides clearer and more consistent naming for shared types, improving code readability and maintainability.
130-130
: Confirm the change in return type toScalarBoolean1
The return types of the
upload
andupload_many
functions have been changed toMutationNode<ScalarBoolean1>
. Please verify that this change is intentional and ensure that all calling code handles the new return type correctly to prevent potential runtime errors.Also applies to: 148-148
tests/metagen/typegraphs/sample/rs/client.rs (2)
88-90
: Updated argument types inRootScalarArgsFn
enhance type consistencyThe argument types for
id
,slug
, andtitle
have been updated to useScalarStringUuid1
andScalarString1
, aligning with the new scalar type definitions and improving type consistency across the codebase.
227-233
: Consistent scalar type definitions intypes
moduleThe
types
module now usesScalarStringUuid1
andScalarString1
for type aliases and struct fields, providing a consistent and clear type system that enhances code readability.tests/metagen/typegraphs/identities/ts/fdk.ts (4)
36-47
: Updated scalar type definitions improve code clarityIntroducing scalar types like
ScalarString1
,ScalarInteger1
, and others standardizes the type definitions, enhancing code clarity and consistency across the codebase.
49-60
: RefactoringPrimitives
to use new scalar typesThe
Primitives
type now relies on the updated scalar types, which improves the consistency of type usage and simplifies understanding of the underlying data structures.
65-85
: Consistent naming in composite typesComposite types such as
CompositesOptScalarString1Optional
andCompositesListScalarString1List
now use the new scalar type names, ensuring consistent naming conventions throughout the code.
118-128
: Enhanced clarity in cyclic type definitionsThe cyclic types like
SimpleCycles1
,SimpleCycles2
, andSimpleCycles3
have been updated to use the new scalar type definitions, which improves readability and helps prevent potential confusion in the cyclic relationships.examples/typegraphs/metagen/rs/fdk.rs (3)
222-224
: LGTM! Type aliases follow the new naming convention.The renaming from specific prefixes to generic
Scalar
prefixes aligns with the PR objective to fix naming of shared types.
227-232
: LGTM! Struct fields consistently use the new type aliases.The field types are correctly updated to use the new scalar types while preserving the serde attributes.
112-112
: Verify version compatibility.The version bump from
rc.8
torc.9
aligns with the API changes for type naming. Please ensure all dependent packages are updated accordingly.✅ Verification successful
Version update is consistently applied
The version bump to
0.5.0-rc.9
has been properly synchronized across all relevant files in the codebase, including package manifests, source files, and tests. The only expected difference is intools/consts.ts
wherePUBLISHED_VERSION
tracks the previous release.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for version references across the codebase. # Search for version string references rg -g '!target' -g '!*.lock' '"0.5.0-rc.[0-9]"'Length of output: 1565
tests/metagen/typegraphs/sample/rs/main.rs (5)
41-42
: LGTM! Type update follows the new naming convention.The type has been correctly updated to use
ScalarStructShared2Partial
while preserving the closure logic.
101-104
: LGTM! Mutation correctly uses the new type.The mutation has been updated to use
ScalarStructShared2Partial
while maintaining the same structure.
110-116
: LGTM! Query correctly uses the new type.The
scalar_union
query has been updated to useScalarStructShared2Partial
consistently.
123-127
: LGTM! Query correctly uses the new type.The
composite_union
query has been updated to useScalarStructShared2Partial
while preserving the selection structure.
Line range hint
130-137
: LGTM! Query correctly uses the new type.The
mixed_union
query has been updated to useScalarStructShared2Partial
while maintaining the selection structure.tests/runtimes/wasm_wire/rust/fdk.rs (3)
112-112
: Version update is consistent.The version bump matches other files in the codebase.
222-268
: LGTM! Comprehensive update to new type naming convention.The changes consistently apply the new scalar type naming convention across all type aliases and struct fields while preserving serde attributes.
293-293
: LGTM! Handler signature updated correctly.The handler's return type has been updated to use the new scalar type.
tests/metagen/typegraphs/identities/rs/fdk.rs (3)
222-233
: LGTM! Basic scalar types follow the new convention.The type aliases consistently use the "Scalar" prefix and maintain appropriate primitive type mappings.
236-248
: LGTM! Struct fields consistently use new scalar types.The field types have been updated to use the new scalar types while preserving serde attributes and documentation.
Line range hint
254-340
: LGTM! Complex types consistently use new naming convention.The changes maintain type relationships and hierarchy while adopting the new scalar type naming convention throughout complex and nested structures.
src/typegraph/core/src/utils/postprocess/naming.rs (8)
13-13
: LGTM: Import of IndexSet for efficient reference tracking.The IndexSet provides both set operations and indexing, which is ideal for tracking type references.
36-42
: LGTM: Reference counting initialization.The implementation correctly initializes reference counting before processing types, which is essential for tracking shared types.
44-50
: LGTM: Enhanced VisitCollector initialization.The collector now includes reference counting data and name occurrence tracking, which supports the new naming strategy.
77-80
: LGTM: New fields in VisitCollector.The added fields support reference counting and name tracking:
counts
: Maps type IDs to their referrersname_occurences
: Tracks name usage frequency
82-95
: LGTM: TypeRefCount implementation.Clean implementation of reference counting with:
- Efficient storage using HashMap and IndexSet
- Clear method for updating references
97-117
: LGTM: Helper methods for name generation.Well-implemented helper methods:
has_more_than_one_referrer
: Clear check for shared typesnext_name
: Generates unique names with incrementing counters
275-335
: LGTM: Comprehensive reference collection implementation.The
collect_ref_info
function correctly:
- Handles all type variants
- Skips user-named types
- Uses visited set to prevent redundant processing
Note: Previous concerns about cyclic references are addressed by the codebase's design where cyclic types can only occur with user-renamed types, which are skipped by this processor.
Line range hint
338-374
: LGTM: Enhanced name generation logic.The updated
gen_name
function now:
- Preserves user-named types
- Uses scalar naming for basic types
- Handles shared types with special naming
src/typegate/src/typegraphs/introspection.json (1)
48-48
: LGTM: Consistent scalar type naming.The renaming follows the new convention for scalar types:
- Basic string type →
scalar_string_1
- Optional string type →
scalar_string_1_optional
- Boolean type →
scalar_boolean_1
Also applies to: 102-102, 130-130, 136-136
src/typegate/src/typegraphs/typegate.json (1)
86-86
: LGTM: Consistent scalar and shared type naming.The renaming follows the established convention:
- Scalar types:
scalar_string_1
,scalar_boolean_1
, etc.- Shared types:
scalar_struct_shared_1
,scalar_struct_shared_2
, etc.- Enums:
scalar_string_enum_1
,scalar_string_enum_2
, etc.Also applies to: 112-112, 116-116, 201-201, 243-243, 299-299, 304-304, 443-443, 480-480, 599-599, 700-700, 706-706, 780-780
What was that proposal of yours to avoid stability issues around the numbers? The current names would change when you expose new functions that are not placed at the end. Edit: right, using the reference count? Wouldn't that lead to duplicate names? |
How about, alternatively, we use "short hashes of the first reference path" in the name? This way, we get stability based on graph location without having to use the path location in the name. |
No it's not using the ref count, it's just returning the type name and if it's already used it will increase the suffix by 1 (so it's increasing if a dup is encountered). This seemed more natural than keeping the ids. Also, I was curious of the count at which a scalar type was duplicated on our snapshots. |
Like taking the first n chars of each path segment? Or directly hash it...? |
Ah, I see what you mean by dup count. It's stability is much better, but all the numbers will change if you add a new func that has uses the same "kind" before the others, the old types of the same kind will have their reference indices incremented.
Directly hashing it. So you'd have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (3)
tests/metagen/typegraphs/sample/ts/client.ts (1)
1020-1021
: Consider defining a specific type forid
inStructC339c
The
id
field is currently typed asstring
. Ifid
s have specific formats or constraints (e.g., UUIDs), defining a custom type could help enforce these rules at the type level.src/typegraph/core/src/utils/postprocess/naming.rs (2)
77-94
: Add documentation for the reference counting implementation.The new reference counting functionality using
IndexSet
would benefit from documentation explaining:
- The purpose of tracking references
- Why
IndexSet
was chosen over a regularHashSet
- How the reference counting affects the naming strategy
Add documentation above the structs:
+/// Tracks references to types using an ordered set to ensure deterministic behavior. +/// Multiple references to the same type are tracked to influence the naming strategy. struct TypeRefCount { pub counts: HashMap<u32, IndexSet<u32>>, } +/// Records when a type is referenced by another type, maintaining the referrer's ID +/// in an ordered set for deterministic processing. impl TypeRefCount { pub fn new_hit(&mut self, id: u32, referrer: u32) {
105-111
: Extract the hash length as a constant.The hash truncation length (5 characters) should be defined as a constant for better maintainability and consistency.
+const NAME_HASH_LENGTH: usize = 5; + impl VisitCollector { pub fn next_name(&mut self, name: String, hash_input: String) -> String { let mut sha256 = Sha256::new(); sha256.update(hash_input.bytes().collect::<Vec<_>>()); let hash = format!("{:x}", sha256.finalize()); - format!("{name}_{}", hash.chars().take(5).collect::<String>()) + format!("{name}_{}", hash.chars().take(NAME_HASH_LENGTH).collect::<String>()) } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (8)
src/typegraph/core/src/snapshots/typegraph_core__tests__successful_serialization.snap
is excluded by!**/*.snap
tests/e2e/typegraph/__snapshots__/typegraph_test.ts.snap
is excluded by!**/*.snap
tests/metagen/__snapshots__/metagen_test.ts.snap
is excluded by!**/*.snap
tests/planner/__snapshots__/planner_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/grpc/__snapshots__/grpc_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/kv/__snapshots__/kv_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/s3/__snapshots__/s3_test.ts.snap
is excluded by!**/*.snap
tests/runtimes/temporal/__snapshots__/temporal_test.ts.snap
is excluded by!**/*.snap
📒 Files selected for processing (11)
examples/typegraphs/metagen/rs/fdk.rs
(1 hunks)src/typegate/src/typegraphs/typegate.json
(10 hunks)src/typegraph/core/src/utils/postprocess/naming.rs
(5 hunks)tests/metagen/typegraphs/sample/py/client.py
(17 hunks)tests/metagen/typegraphs/sample/py_upload/client.py
(3 hunks)tests/metagen/typegraphs/sample/rs/client.rs
(15 hunks)tests/metagen/typegraphs/sample/rs/main.rs
(4 hunks)tests/metagen/typegraphs/sample/rs_upload/client.rs
(6 hunks)tests/metagen/typegraphs/sample/ts/client.ts
(9 hunks)tests/metagen/typegraphs/sample/ts_upload/client.ts
(3 hunks)tests/runtimes/wasm_wire/rust/fdk.rs
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- tests/metagen/typegraphs/sample/rs/main.rs
- examples/typegraphs/metagen/rs/fdk.rs
- tests/metagen/typegraphs/sample/rs/client.rs
🧰 Additional context used
📓 Learnings (1)
src/typegraph/core/src/utils/postprocess/naming.rs (1)
Learnt from: michael-0acf4
PR: metatypedev/metatype#955
File: src/typegraph/core/src/utils/postprocess/naming.rs:258-305
Timestamp: 2025-01-07T20:11:43.287Z
Learning: In the Metatype codebase's type system (src/typegraph/core/src/utils/postprocess/naming.rs), cyclic types can only occur with user-renamed types, as a reference can only exist after a rename happens. These cycles are naturally handled because the naming post-processor skips processing of user-renamed types.
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: bulid-docker (linux/arm64, custom-arm)
- GitHub Check: test-full
- GitHub Check: lint-compat (macos-14, aarch64-apple-darwin, false)
- GitHub Check: bulid-docker (linux/amd64, custom-ubuntu-large)
- GitHub Check: lint-compat (macos-13, x86_64-apple-darwin, false)
- GitHub Check: pre-commit
🔇 Additional comments (28)
tests/metagen/typegraphs/sample/rs_upload/client.rs (6)
45-48
: Type naming improved for shared typesThe updated type names without function prefixes, such as
FileBf9b7
andRootUploadFnInputPathString25e51Optional
, align with the PR's objective to improve clarity by avoiding misleading prefixes. This change enhances readability and reduces confusion.
65-69
: Consistent naming of shared types in function argumentsThe argument types in
RootUploadManyFn
have been updated toRootUploadManyFnInputPrefixString25e51Optional
andRootUploadManyFnInputFilesFileBf9b7List
, promoting consistent and clear naming conventions for shared types across the codebase.
84-96
: Updated type aliases and struct fields for clarityThe type aliases and struct fields have been updated to use the new shared type names. This ensures consistency and aligns with the goal of reducing ambiguity in type definitions.
106-117
: Ensured correct GraphQL type mappingsThe
ty_to_gql_ty_map
inQueryGraph::new
has been updated with the new type mappings corresponding to the renamed shared types. This change ensures correct type resolution when interfacing with GraphQL.
146-146
: Verify handling of the updated return type inupload_many
The return type of the
upload_many
method has been changed toMutationNode<bool>
. Ensure that all calls to this method are updated to handle the new return type appropriately.Run the following script to find usages of
upload_many
and verify proper handling:✅ Verification successful
Return type handling for
upload_many
is properly implementedAll existing calls to
upload_many
are already wrapped in appropriate mutation contexts and handle theMutationNode<bool>
return type correctly.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all usages of the `upload_many` method in the codebase. rg -A 2 'fn upload_many\('Length of output: 288
Script:
#!/bin/bash # Search for method calls with context rg -A 2 '\.upload_many\(' || true rg -A 2 '= .*upload_many\(' || true # Use ast-grep to find method calls (Rust pattern) ast-grep --pattern 'upload_many($$$)' || trueLength of output: 1013
128-128
: Verify handling of the updated return type inupload
The return type of the
upload
method has been changed toMutationNode<bool>
. Please verify that all usage of this method correctly handles the new return type.Run the following script to find usages of
upload
and check for proper handling:✅ Verification successful
Return type
MutationNode<bool>
is properly handledThe verification confirms that the return type is correctly handled in all usages. The code in
main.rs
demonstrates proper handling in both synchronous and asynchronous contexts, with the results being correctly processed through the GraphQL client interface.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all usages of the `upload` method in the codebase. rg -A 2 'fn upload\('Length of output: 274
Script:
#!/bin/bash # Search for calls to upload method and MutationNode<bool> type echo "=== Searching for upload method calls ===" rg -l "\.upload\s*\(" echo -e "\n=== Searching for MutationNode<bool> references ===" rg -l "MutationNode\s*<\s*bool\s*>" echo -e "\n=== Checking the content of the client.rs file ===" cat tests/metagen/typegraphs/sample/rs_upload/client.rsLength of output: 5943
Script:
#!/bin/bash # Check the content of main.rs to verify proper handling echo "=== Checking main.rs content ===" cat tests/metagen/typegraphs/sample/rs_upload/main.rsLength of output: 3919
tests/runtimes/wasm_wire/rust/fdk.rs (1)
112-112
: Verify consistent version update to0.5.0-rc.9
The
MT_VERSION
has been updated to"0.5.0-rc.9"
. Please ensure that all other references to the Metatype version in the codebase are updated accordingly to maintain consistency.Run the following script to locate any remaining references to the old version:
✅ Verification successful
Version update is consistent across the codebase
The different versions in
tools/consts.ts
appear intentional:
METATYPE_VERSION = "0.5.0-rc.9"
(current version)PUBLISHED_VERSION = "0.5.0-rc.8"
(last published version)All other files have been correctly updated to version
0.5.0-rc.9
.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find any remaining references to `0.5.0-rc.8` in the codebase. rg '0\.5\.0-rc\.8'Length of output: 83
Script:
#!/bin/bash # Search for the new version and any other version patterns echo "=== Searching for new version ===" rg '0\.5\.0-rc\.9' echo -e "\n=== Searching for any version pattern ===" rg '0\.5\.0-rc\.[0-9]+' echo -e "\n=== Searching without escaped dots ===" rg '0.5.0-rc.[0-9]+'Length of output: 9474
tests/metagen/typegraphs/sample/ts/client.ts (5)
919-920
: Ensure type safety with the new argument typesThe
argumentTypes
forslug
andtitle
have been changed toStringE1a43
. Verify that any specific validations or constraints previously associated with these types are still enforced after this change.
1031-1032
: Confirm correctness of union types includingstring
andnumber
The union types
RootScalarUnionFnOutput
andRootMixedUnionFnOutput
now include bothstring
andnumber
. Please ensure that this change accurately reflects the intended possible return types and that all consumers of these types can handle both cases.Also applies to: 1039-1040
1104-1105
: Updated type mappings in type name mapThe
typeNameMapGql
has been updated withStringE1a43
. This change ensures that the new types are correctly mapped for GraphQL operations.
1132-1140
: Verify impact of changing return types tostring
The return types of
scalarNoArgs
andscalarArgs
have been changed toQueryNode<string>
andMutationNode<string>
respectively. Confirm that this change does not affect any functionality dependent on the previous types.
1150-1174
: Ensure correct handling of updated argument types in methodsThe methods
compositeArgs
,scalarUnion
,compositeUnion
, andmixedUnion
now acceptStructC339c
as arguments. Verify that the changes are properly integrated and that all calls to these methods are updated accordingly.src/typegraph/core/src/utils/postprocess/naming.rs (1)
269-329
: Well-implemented reference collection with cycle handling!The
collect_ref_info
function effectively traverses the type graph while:
- Properly handling user-renamed types that could form cycles
- Using a visited set to prevent revisiting nodes
- Cleaning up the visited set after processing each branch
src/typegate/src/typegraphs/typegate.json (1)
86-86
: Verify impact of type name standardization.The type names have been standardized with hash suffixes (e.g.,
struct_542d7
,string_5d176
,string_json_df54e
). While this improves consistency, ensure that all consumers of these types have been updated accordingly.Also applies to: 112-112, 201-201, 271-271, 299-299, 304-304
✅ Verification successful
Type name standardization appears to be self-contained
The type name changes are limited to the type definitions in
typegate.json
with no references found in any TypeScript or JavaScript files. The changes appear to be safe and self-contained within the type definition file.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for old type names in the codebase rg -l "root_typegraphs_fn_input|Typegraph_name_string|root_addTypegraph_fn_output_failure"Length of output: 134
Script:
#!/bin/bash # Get context around the matches rg -C 3 "root_typegraphs_fn_input|Typegraph_name_string|root_addTypegraph_fn_output_failure" src/typegate/src/typegraphs/typegate.json # Look for any code references to these types fd -e ts -e js -e tsx -e jsx | xargs rg "root_typegraphs_fn_input|Typegraph_name_string|root_addTypegraph_fn_output_failure"Length of output: 436
tests/metagen/typegraphs/sample/ts_upload/client.ts (4)
885-886
: Type naming changes look consistent.The argument types in
RootUploadFn
andRootUploadManyFn
have been updated to use hash-suffixed type names (FileBf9b7
,String25e51Optional
) instead of function-prefixed names. This change aligns with the PR objective of improving shared type naming.Also applies to: 895-896
902-912
: Type definitions follow the new naming convention.The type definitions use consistent hash suffixes to identify shared types:
FileBf9b7
for file typesString25e51Optional
for optional string types
This improves type identification across the codebase without relying on function prefixes.
919-922
: GraphQL type mappings are properly updated.The GraphQL type mappings in the
QueryGraph
constructor have been updated to match the new type names, maintaining consistency between TypeScript and GraphQL types.
932-932
: Return type change to boolean is consistent.The return types for both
upload
anduploadMany
methods have been changed toMutationNode<boolean>
. This change appears to be part of a broader API refinement.Let's verify this change is consistent across implementations:
Also applies to: 940-940
✅ Verification successful
Return type change to boolean is consistently implemented.
The change to
MutationNode<boolean>
is verified to be consistent across:
- Both
upload
anduploadMany
methods- All language implementations (TypeScript, Rust, Python)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the return type change is consistent across implementations rg -A 1 "upload.*MutationNode.*bool" tests/metagen/typegraphs/Length of output: 64
Script:
#!/bin/bash # Find upload method declarations and their return types ast-grep --pattern 'upload($_): $_ { $$$ }' # Find MutationNode type usage rg "MutationNode" tests/metagen/typegraphs/ -B 1 -A 1 # Find all upload-related method implementations rg "upload.*\(" tests/metagen/typegraphs/ -B 1 -A 1Length of output: 16747
tests/metagen/typegraphs/sample/py_upload/client.py (4)
831-832
: Python type definitions match TypeScript implementation.The argument types in
NodeDescs.RootUploadFn
andNodeDescs.RootUploadManyFn
have been updated to use the same hash-suffixed type names as the TypeScript implementation:
FileBf9b7
String25e51Optional
This ensures consistency across language implementations.Also applies to: 844-845
851-873
: Type aliases and TypedDict definitions are properly structured.The type definitions follow Python's typing conventions while maintaining consistency with the TypeScript implementation:
FileBf9b7
is aliased toFile
RootUploadFnInput
andRootUploadManyFnInput
are properly defined as TypedDicts with optional fields
882-885
: GraphQL type mappings are consistent with TypeScript.The GraphQL type mappings in the Python
QueryGraph
constructor match those in the TypeScript implementation, ensuring consistent type handling across languages.
891-891
: Return type changes match TypeScript implementation.The return types for both
upload
andupload_many
methods have been changed toMutationNode[bool]
, consistent with the TypeScript changes.Also applies to: 901-901
tests/metagen/typegraphs/sample/py/client.py (6)
876-877
: Consistent type naming improvements across functions.Multiple functions have been updated to use the new type naming convention:
StringE1a43
replaces custom string types- Type names are consistent across different functions
This change simplifies the type system while maintaining type safety.Also applies to: 896-896, 907-907, 927-927, 947-947
1001-1002
: Type definitions simplified and standardized.
- Post type fields now use
str
instead of custom string types- New
StructC339c
type introduced with consistent naming
This simplification makes the code more maintainable while preserving type safety.Also applies to: 1007-1010
1030-1031
: Union type definitions updated consistently.Union types have been updated to use simpler primitive types where appropriate:
str
andint
for scalar unions- Consistent naming across different union types
Also applies to: 1044-1045
1052-1052
: Nested type definitions properly updated.All nested type definitions have been updated to use consistent type names and primitive types where appropriate. The changes maintain the structure while improving naming consistency.
Also applies to: 1060-1060, 1069-1069, 1081-1081
1182-1182
: GraphQL type mapping updated.The GraphQL type mapping has been updated to include the new
StringE1a43
type, maintaining consistency between Python types and GraphQL schema.
1204-1204
: Method signatures updated consistently.All method signatures have been updated to use the new type names:
- Return types use
str
instead of custom string types- Arguments use
StructC339c
consistently
The changes maintain API compatibility while improving type naming.Also applies to: 1214-1214, 1233-1233, 1245-1245, 1256-1256, 1270-1270
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #955 +/- ##
=======================================
Coverage 77.98% 77.98%
=======================================
Files 154 154
Lines 19082 19082
Branches 1929 1929
=======================================
Hits 14882 14882
Misses 4177 4177
Partials 23 23 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A great improvement but due to concern below, I wonder if we should restrict this behavior to scalars?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/typegate/src/typegraphs/typegate.json (1)
336-336
: LGTM! Consider documenting the new naming scheme.The complex type renames maintain consistency and properly handle type references. The new naming pattern (
type_hash
) makes it easier to identify shared types across the schema.Consider adding a comment in the schema or documentation explaining the new naming convention for better maintainability. Example:
{ + // Type naming convention: + // - Basic types: <type>_<hash> (e.g., string_5d176) + // - Complex types: <type>_<hash> (e.g., struct_8f8a3) + // The hash is derived from the first reference path to maintain stability "types": [Also applies to: 372-372, 378-378, 383-383, 443-443, 599-599
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/typegate/src/typegraphs/typegate.json
(10 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: lint-compat (macos-14, aarch64-apple-darwin, false)
- GitHub Check: lint-compat (macos-13, x86_64-apple-darwin, false)
- GitHub Check: bulid-docker (linux/amd64, custom-ubuntu-large)
- GitHub Check: test-full
- GitHub Check: pre-commit
🔇 Additional comments (1)
src/typegate/src/typegraphs/typegate.json (1)
86-86
: Verify impact of type renaming on user code.The renaming of root function input/output types (e.g.,
root_typegraphs_fn_input
→struct_542d7
) could affect user code that directly references these types. While the new naming scheme using type-hash pairs (e.g.,string_5d176
) is more consistent, we should ensure this change doesn't break existing implementations.Also applies to: 112-112, 201-201, 271-271, 299-299, 304-304, 780-780
Since types can be shared, prefixing the name with the first function/path encountered would be confusing for the other types that also refers to it. This patch disables prefixing for types with more than one referrer. #### Migration notes None - [ ] The change comes with new or modified tests - [ ] Hard-to-understand functions have explanatory comments - [ ] End-user documentation is updated to reflect the change <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit Based on the comprehensive summary of changes across multiple files, here are the updated release notes: - **Type System Refinement** - Standardized type naming conventions across multiple languages. - Replaced specific type aliases with more generic scalar types. - Updated function signatures to use simplified type definitions. - **Version Updates** - Incremented metatype version from "0.5.0-rc.8" to "0.5.0-rc.9". - **Upload Functionality** - Modified file upload method return types to return boolean instead of complex output. - Updated argument types for upload-related functions. - **Performance and Naming Improvements** - Enhanced reference counting for type naming processor. - Refined type generation logic with more consistent naming strategies. These changes primarily focus on improving type system consistency and simplifying type definitions across different runtime environments. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Since types can be shared, prefixing the name with the first function/path encountered would be confusing for the other types that also refers to it.
This patch disables prefixing for types with more than one referrer.
Migration notes
None
Summary by CodeRabbit
Based on the comprehensive summary of changes across multiple files, here are the updated release notes:
Type System Refinement
Version Updates
Upload Functionality
Performance and Naming Improvements
These changes primarily focus on improving type system consistency and simplifying type definitions across different runtime environments.