Just tried out Dariusz Łuksza's fantastic Fan <-> Mongo driver, Fanlink

Question: does this only work with immutable objects?

Seems like the MongoDoc mixin requires concrete classes to be const, and all fields const too?

And documenting my discoveries as I go along here. Seems like classes need to be structured thus:

using fanlink
using mongo

const class Person : MongoDoc {
  const Str? name
  const override ObjectID? _id
    new make(|This f| f) {
    f(this)
  }
}

Seems that classes can contain lists of other MongoDocs.

Yes, MongoDoc objects must be const classes. This is side effect of making FindFilter const class. I personally prefer such approach, bur we can discuss both approaches.

Yes, classes can have "nested" MongoDoc's, MongoDoc's list and maps with MongoDoc values. Fanlink would convert nested MongoDoc object into nested Str:Obj? map, in case of List[MongoDoc] this would be converted to List[Str:Obj?]. Also maps with MongoDoc value would be converted to Map[Str:Map[Str:Obj?]]. Of course nested objects can also have MongoDoc objects ;) only limitation here is stack size, because currently extracting nested object uses recursive call.

Hacked my local copy of the project, removed const from MongoDoc.fan and FindFilter.fan, also removed toImmutable from Operations class.

Now I can make changes to a MongoDoc, however persisting the object again results in a new object with a new id.

So, either we have to delete, then reinsert an object, or find a way to update in place. Actually, an upsert function might be useful.

Am also wondering if there shouldn't be 2 MongoDocs:

• a Mutable one, and
• an Immutable one?

Dave

Operations.insert will always insert new entry. There are two other methods:

* save * update available on fantomongo driver with should be added into fanlink breadge. I'll add those operations tomorrow, now I need to get some sleep ...

I don't think that we need to have two versions of MongoDoc. When you need to change something in document you should "clone" existing one and change required values (setting at least old _id from previous version)

@dluksza: Clone seems problematic for a number of reasons:

• cloning: I'm not familiar enough with Fantom to know if there is a way to do deep cloning automatically. If not, this is going to become error prone with rich domain models, and potentially quite inefficient (eg with deeply nested domain models)
• changing object ids: Assume I'm looking at a row of users in a table. Each one has an objectid which I can use to find the object with if I need more detail, or if I need to mutate its state. In the meantime, a different client edits the object and persists it with a new id. Now my id no longer points to that object (or any object in the db).

If I recall from CouchDB, which doesn't allow update in place, they use an _id and a _rev. So, you can cache your object locally, and use the revision to find out if your copy is stale. This would seem to be neccessary in Fanlink too if you don't allow update in place.

However, given that Mongo allows update in place, why not simply use it?

I've updated FanLink to support update operation. For now it still required MongoDoc objects to be const, but I'm close to change this requirements based on yours arguments.

BTW. During implementing update functionality I've found bug in fantomongo ObjectID implementation, so if you want run tests and got all of them pass you need to use my forked version of fantomongo

Hi @dluksza, I was wondering if sort operations where supported (not that I can see). Also I was wondering if it was possible to do a search(find) with a pattern (similar to a like query in sql).

I don't think that fanlink supports that as far as I can tell. Alternatively could I use fantomongo directly to run such a query and then have fanlink deserialize it into my MongoDoc object ?

Thanks