Haha, I wasn't sure if it made sense to add support for my personal project in a Google project, but from the looks of it, I worried for nothing 😛

Is this being worked on at the moment @rrousselGit ?

Freezed requires as String conversion on each field like Timestamp. The one solution - custom converters and a paramer like notjson:true on @freezed

+1 for adding freezed support, current use-case is the copyWith and == generation

Hi all. Freezed support is now planned, see: #9294

Any update on this?

We still can't use nested class or it's fix ? Can't find anywhere the repo cloud_firebase_odm to see issues.

This URL is broken https://github.com/firebase/flutterfire/tree/master/packages/cloud_firestore_odm (from the doc https://firebase.flutter.dev/docs/firestore-odm/defining-models)

Is there any updates on this? I want to create an array nested in the main document. And use the array-contains query.
I haven't tried the generic whereFieldPath method, I have a feeling that this will work. However, an explicitly generated method would be preferable.

Any updates on this? Spent quite a bit of time trying to figure out how to do nested Objects. Suggestion, so that other people don't spend time on finding info, maybe to add info that nested objects aren't supported. Also if there is visibility to the roadmap or planned features, that might also help. Loving the package anyways! Good job!

Note that it isn't necessary though.
You could use @Collection and achieve the same result:

class Model {...}

@Collection<Model>('other')
final document = ModelCollectionReference().doc('my-doc');

As a workaround sure, but creating multiple competing references depending on the one document you want to get seems pretty counterintuitive.

@rrousselGit in your example, the string my-doc is the path or id to the document.
is there a way to reference the path stored in a field of the parent doc?
ex: product has a field that references a company.

Could I do something like this:

class Product {...}

@Collection<Product>('products')
@Collection<Company>('companies')
final companyRef = ProductCollectionReference().doc().data['company']

or would we use the to-be-created @Document annotation ?

class Product {...}

@Collection<Product>('products')
@Document<Company>('companies', name: 'company')
final companyRef = ProductCollectionReference()

@AirborneEagle I don't understand your examples. How would that look like in firestore?

@AirborneEagle This will work, yes. You just have to specify different prefixes in the Collection() annotation.

As it currently is, the provided workaround is good enough and a document annotation shouldn't be necessary since Firestore isn't supposed to be used like that anyway

Yes, it is planed. It will have a clone of the paginated flutterfire_ui components

IS there any beta version or a feature branch that has this? I would like to try on this.

No, not yet.

is everyone currently doing pagination manually? Wondering if there is a way to use something like FirestoreListView with odm ?

Any plans for pagination to be supported?

You need to change your Dart SDK version to:

environment:
  sdk: ">=2.14.0 <3.0.0"

For reference, I've updated the installation docs to mention that step

Alternatively (if you have a half-migrated codebase), you can add a dart version override to the top of the file:

// @dart=2.15

Please include this in the doc

Do you have some code that you could share to reproduce the issue?

In copying my code over I realized my mistake. I ended up with FirestoreBuilder<MixDocumentReference> instead of FirestoreBuilder<MixDocumentSnapshot>. Got it working now. Thanks for the response.

I did find I had to implement a custom fromJson for a DateTime field. Adding that to the automagic types would be a nice addition.

@AgDude You can do that by using a custom Jsonserializable annotation where you pass the converter directly. Then you just replace your JsonSerializable annotations with the custom one and you're good to go

There is currently no such thing.

I've raised an issue #7613

This got me pretty far @Lyokone in the existing non-ODM package.

import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:my_package/models/event.dart';

static FirebaseFirestore firestore = FirebaseFirestore.instance;
  static CollectionReference<Event> eventCollection =
      FirebaseFirestore.instance.collection('events').withConverter<Event>(
            fromFirestore: (snapshots, _) {
              var data = snapshots.data()!;
              return Event.fromJson(data).copyWith(id: snapshots.id);
            },
            toFirestore: (object, _) => object.toJson(),
          );

I'll need a bit of work – particularly google/json_serializable.dart#1072

I'll make a PR when I can

There seems to be progress on this (the json_serializable PR is merged), but until this makes it here, here is the converter I've written (if this can help). Let me know if I missed something.

// Firestore does not actually returns Json for Timestamps, they are already converted, hence this 1:1 converter
class TimestampConverter implements JsonConverter<Timestamp, Timestamp> {
  const TimestampConverter();

  @override
  Timestamp fromJson(Timestamp json) => json;

  @override
  Timestamp toJson(Timestamp object) => object;
}

I reckon this might be incoming following Timestamp support, but the orderBy functions are not generated for Timestamp fields.

It won't help, no.
But you could specify a default value on nickname, avoiding the need for a migration altogether

@rrousselGit thanks. I'll prefer nullable type then. I was considering using Firestore ODM for the migration case, but will integrate it after its stable. Thanks for all your work! 🔥

In my case I done this by adding the JsonKey to the field and using this Json converters

@JsonKey(
    toJson: firestoreListDocRefToJson,
    fromJson: firestoreListDocRefFromJson,
  )
  List<DocumentReference> members;

DocumentReference firestoreDocRefFromJson(dynamic value) {
  if (value is String) {
    return FirebaseFirestore.instance.doc(value);
  } else {
    return FirebaseFirestore.instance.doc(value.path);
  }
}

dynamic firestoreListDocRefToJson(dynamic value) => value;

List<DocumentReference> firestoreListDocRefFromJson(List value) {
  final List<DocumentReference> list = [];
  for (var element in value) {
    list.add(firestoreDocRefFromJson(element));
  }
  return list;
}

Thank you very much! I'll try this out.

This worked!! thanks @damalo93

You can also easily extend this method to use other generated document references instead of the generic DocumentReference.
I chose to store just the id, but if you want you can also just do value.refernece instead.

UserDocumentReference docRefFromJson(String id) => usersRef.doc(id);
String docRefToJson(UserDocumentReference value) => value.id;

(With documentReference, I did not test this)

UserDocumentReference docRefFromJson(DocumentReference doc) => usersRef.doc(doc.id);
DocumentReference docRefToJson(UserDocumentReference value) => value.reference;

Shouldnt be an issue. Besides if you couldn't export stuff from Multi-Part files, then what's the point of creating them?

That isn't currently available, but it is discussed in #7613 . My current workaround is that I attach the snapshot to the model immediately after it is fetched.

For example I have a model called Mix

return FirestoreBuilder<MixDocumentSnapshot>(
      ref: mixManager.doc(widget.mixId),
      builder: (context, AsyncSnapshot<MixDocumentSnapshot> snapshot, Widget? child) {
        if (snapshot.hasError) return Text('Something went wrong!');
        if (!snapshot.hasData) return Text('Loading mix...');

        MixDocumentSnapshot mixSnapshot = snapshot.requireData;
        if (!mixSnapshot.exists) {
          return Text('Not Found!');
        }

        Mix mix = mixSnapshot.data!;
        mix.snapshot = mixSnapshot;
        return SomeWidget(mix)
)

The other advantage of this pattern is that it gives me access to subcollections easily from within the mix model using snapshot.reference.mySubCollection

Thanks @AgDude! I was also doing it this way, but was still getting an error. I had to ignore the late id and make it not required in the constructor of my model.

@JsonKey(ignore: true)
late String uid;

FieldMap is a requirement though

I assume it's an optimisation requirement, but it makes little sense if the ODM generator works with manual serialization.

Example: If you have a package with models where you defined json serialization manually, and make another package for collections, the ODM generator works just fine.

Now if you decide to make the domain models package serialization to be generated with json_serializable. The result is the same as far as the model package is concerned, although that serialization has been generated it shouldn't be a concern.

it makes little sense if the ODM generator works with manual serialization

It doesn't.

fieldMap is necessary for when the name of a value inside a Dart class vs inside the DB are different. Like having firstName locally vs user_name on remote.

Without fieldMap, updating/querying those fields wouldn't work.

It doesn't.

Maybe we are talking about different things because it compiles for me. With this manually written in the class and no dependency on json_serializable:

class Something {

Map<String, dynamic> toJson() => ...
factory fromJson() => ...  

I don't know the internal of ODM and how it uses field map but unless it was some hiccups on my part I believe that works.

Note: something is in package a and somethingCollection in package b. If package a uses json_serializable to generate the same code, it stops working.

Note 2: I've only checked compilation, not runtime.

This isn't about a compilation error but a runtime error.

It's string based. It's effectively as if you were to pass the wrong field name when not using the ODM

You should create a separate issue as this is not a related to API feedback.

The ODM doesn't implement the FIrestore "DocumentReference" API. It generates custom types instead.

But the custom types can be converter back using their .reference property. You likely want to pass that in

Yes

They need to be queries separately. Subcollections are just a neat way to access them, but otherwise not different from plain Firestore

See #11728, you will find there a workaround.

Hey, Freezed now annotate with JsonSerializable _$ClassNameImpl and so JsonSerializable generate now _$$ClassNameImplWhatever.

A fix could be a little change of _generatedJsonTypePrefix from collection_data.dart

For :

static String _generatedJsonTypePrefix({
    required bool hasFreezed,
    required String? redirectedFreezedClass,
    required String collectionTargetElementPublicType,
  }) {
    if (hasFreezed) {
      return '${redirectedFreezedClass.replaceFirstMapped('_', (match) => '_\$\$')}';
    } else {
      return '$collectionTargetElementPublicType';
    }
  }

Hope this help 😉

A fix is in progress

I created a PR for this FirebaseExtended/firestoreodm-flutter#3

same? #12240

Glad to hear that. However, it seems there are others who share my concerns.
FirebaseExtended/firestoreodm-flutter#7 (comment)

@rrousselGit I created a PR to support batch operations: FirebaseExtended/firestoreodm-flutter#3
I hope it'll be useful for the project

Interesting! Sorry, I missed your notification.

@rrousselGit @Ehesp There hasn't been a new version since October 2024!
There are lots of breaking changes in latest Flutter versions (particularly in cloud_firestore_odm_generator). Is it possible to bump dependencies?

For anyone else facing issues upgrading to the latest Flutter version you can use these in your pubspec.yaml

dependencies:
  cloud_firestore_odm:
    git:
      url: https://github.com/Flutter-Fox/firestoreodm-flutter.git
      ref: fix/migration
      path: packages/cloud_firestore_odm/

dependency_overrides:
  analyzer: "7.7.1"
  dart_style: "3.1.1"

dev_dependencies:
  cloud_firestore_odm_generator:
    git:
      url: https://github.com/Flutter-Fox/firestoreodm-flutter.git
      ref: fix/migration
      path: packages/cloud_firestore_odm_generator/

You didn't fully follow the installation steps and did not enable all necessary json_serializable flags

I followed it from https://firebase.flutter.dev/docs/firestore-odm/defining-models. here, what do you think i might have missed

https://github.com/firebaseextended/firestoreodm-flutter?tab=readme-ov-file#5-enable-create_field_map-and-create_per_field_to_json-of-json_serializable

Consider it v0.88.0, since v0.88.0 had a breaking change.

Very excited about this! Status of original Firestore ODM has been a worrying point, although I’ve been able to work around the limitations without bigger problems. Will try out the package and potentially migrate my app to use it. Effort on the new package highly appreciated!

bro you are my life saver! Keep up please!!

Nicee, this is just amazing! The documentation is super helpful

Also do you think you could bump the dependencies to use the latest build tools? e.g source_gen: ^3.1.0 and build: ^3.1.0