Feature Request(s)

[mands]

Hi - thanks for creating this project, was looking for something to help with this exact use case as have a mixed Python BE and TS FE using Firestore with both.

Have a few feature ideas that I hope help make the library more useful (some of which already have open "Issues" so are hopefully planned):

• Right now I can only create a map as an Alias, and then use that to a Document - would be great to specify on the Document directly (dup of Allow map type for document models #87?)
• An Unknown, or Any type would be really useful for more freeform schemas (dup of Implement unknown type #57?)
• Ability to support additional (typed or Any type) properties on a document, atm I am collecting them in a nested map but this makes the code more complex

Some nice to haves in the future,

• Ability to use an existing Pydantic parent class or Config
• Support for Firebase SERVER_TIMESTAMP

Thanks!

[kafkas]

@mands Thanks for all the feedback!

• Just to clarify, do you mean you want to be able to model a document as an arbitrary map? That is, you want to add top-level arbitrary key-value pairs to a document? If so, then yes Allow map type for document models #87 is the relevant issue. This is actually not a common use case but we'll support that soon regardless (likely this week).
• We'll support unknown type in the next release! May also add any in the same release!
• Not entirely sure I understood this. Would an any type solve this? A document is currently modeled with an object type which requires you to specify the exact fields (including nested fields) on your document. Would be great if you could share what you want the interface of your document to look like and I could let you know how you can model it in Typesync.
• Could you please elaborate on "use an existing Pydantic parent class/Config". Would be great if you could create a separate issue for this. This is something we can likely support.
• The Firebase TS SDKs expose a utility type named WithFieldValue which is used to enhance model types with FieldValue. This lets you add serverTimestamp() to the fields in WithFieldValue<YourTypesyncGeneratedModel>. I'll check how this can be done in Python.

[kafkas]

Also, feel free to ping us on Discord for faster turnaround!

[mands]

Hi, thanks for the reply and the questions, I'll add some code snippets that hopefully help show what I'm trying to do,

1. The issue i'm hitting is that right now to have a Map field in a Document, I need to create an alias first (unless I've missed something), e.g.

StringMap:
  model: alias
  type:
    type: map
    valueType: string

Example:
  model: document
  type:
    type: object
    fields:
      name:
        type: string
      # this crashes
      # properties:
      #  type: map
      #   valueType: string
      properties1:
        type: StringMap

Currently uncommenting the properties field results in a generation failed error, and I have to use the properties1 alias instead.

2. Yes, an unknown / any type would be great, so I can do the following,

StringMap:
  model: alias
  type:
    type: map
    valueType: any # or unknown

Would be great if you could share what you want the interface of your document to look like and I could let you know how you can model it in Typesync.

Yep, of course - don't think I explained clearly, but essentially I'd like to be able to create a Document (or a object) with both known and additional fields, e.g.

Example:
  model: alias
  type:
    type: object
    fields:
      name:
        type: string
      completed:
        type: boolean
      github_url:
        type: string
        optional: true
    additionalFields: true

Which would allow ingesting an object such as,

{
  "name": "Joe Bloggs",
  "completed": false,
  "onboarded": true
}

where onboarded is an additional property, similar to the additionalProperties property in JSONSchema, the [key: string]: string annotation in TypeScript, and extra = Extra.allow in a Pydantic model Config.

4. Yep, so I was thinking a command-line option like --custom-pydantic-base=x.y.MyModel, which would then alter the generated Python code such as,

import x.y.MyModel

class TypesyncModel(x.y.MyModel):
    ...

class Example(TypesyncModel):
    ...

Hope that helps - thanks again for the project, will jump on the Discord. The security rules helpers sound great, migration support for the schemas (forward only, backwards probably not as helpful) would also be a big but great addition!

[kafkas]

Great, thanks for the feedback Mandeep! I'm currently awk and will reply to the other questions later today but in the meantime, to unblock you, I think for question 1, you need to define properties like so:

properties:
  type:
    type: map
    valueType: string

For complex types, type needs to be an object with an inner type field. Could you please give that a try?

[kafkas]

1. I can confirm the following works with Typesync 0.2.1:

Example:
  model: document
  type:
    type: object
    fields:
      name:
        type: string
      properties:
        type:
          type: map
          valueType: string

I recognize the inner type field is a bit inelegant. I'll try to simplify it. It's currently required for types that "are more difficult to explain". We could perhaps rename the inner type to id. Also planning to switch to the map<string, string> syntax sometime soon, which might help with this.

2. ✅
3. I see. I think we can support that. Just created a separate issue Implement config to allow arbitrary properties on object types #119
4. Also can be supported! Just created a separate issue Implement config to have Python classes extend from another base class #120

[mands]

Thanks for your quick replies!

I can confirm the following works with Typesync 0.2.1:

Yes - you are correct, I had missed the inner type field, works now! Perhaps another name would help, id, or even kind may help.

Thanks for creating the other issues and the quick feedback - feel free to close this issue as needed!

[kafkas]

Closing this now but will update you on the other issues!