1 reply
First of all, thx again for your great library !
You might have seen, I've raised an issue with "appName": scullxbones/akka-persistence-mongo#407
Am I right thinking appName in URI should not be ignored, and should default to "akka-persistence-mongodb" ?
Thx in advance,
Hello @scullxbones
Some of our apps are based on a "multi-tenant" architecture, so the software is shared by clients but each one have its own database, collections ...
We'll update a bit the implementation of some persisted actor, and why not using your plugin.
But here is the problem:
As they have their own database, the configuration key akka.contrib.persistence.mongodb.mongo.database is too strict for us.
I quickly thought about it and here is what I would like to suggest:
Having a akka.contrib.persistence.mongodb.mongo.database-resolver configuration key where the value is the FQCN. This class would be responsible to determine the database name when handling persistence based on the PersistenceId for example (could be other like Tag ?)
So it would look like this
// This trait would be in your library
trait DatabaseResolver {
def databaseNameFrom(persistenceId: String): String
}
// This class would be on application side
package a.b.c
class MyDatabaseResolver extends DatabaseResolver {
def databaseNameFrom(persistenceId: String): String = persistenceId.split('_')
}
// In configuration.conf
akka.contrib.persistence.mongodb.mongo.database-resolver = 'a.b.c.MyDatabaseResolver'Do you think this feature would be acceptable in the lib ?
suffixed collection names
Hi @scullxbones,
Happy to see that you are open to add this feature to the lib!
Hmm being an interface is not mandatory, but I think this is the most generic way of doing it, to let application side leading the logic.
That being said, it might be useful to have some provided logics (like regex as you said).
I'll describe what's happening for most of our apps to let you decide if it could be a builtin logic.
Considering
- a persisted actor named
PersonActor - a client named 'potato'
The persistence identifier will have the following format PersonActor|potato_<objectId>
I am not sure but in some cases it could be PersonActor|potato|<objectId>
Any way it could be handled by regex.
But the database name is prefixed by our company name so database name becomes mycompany-potato, mycompany-tomato ...
So in our specific case, having an extra configuration key to add a prefix would be perfect
To conclude the configuration could look like (I omitted akka.contrib.persistence.mongodb.mongo)
// if I want to do it manually
database-resolver = "my.clazz"
// if I want to use the builtin logic described above
database-regex-from-persistence-id = "(regexForEntityTypeHint)|(regexForClient)_(regexForEntityObjectId)" // eg. "(\w+)|(\w+)_([a-z0-9])"
database-regex-prefix = "mycompany"akka specified queries as well as the all events query?
That's ok for me.
Regarding read / query side, my opinion on that is that if you configured your write side as multi-tenant, then the read side should behave the same.
In fact if the application wants to merge differents streams from different tenant, it can be quite easily done with akka streams.
Note that the opposite could be done as well (ie. all events then app filters the events) but, for me, it looks way more dangerous because tenant are mixed by default ...,
and from performance point of view, I think the first one is better as well.
But I have to admit that I don't really know how to handle the tenant from the interfaces provided by Akka.
Those interfaces are bounded to a plugin identifier, and then provides methos which does not have any tenancy stuff.
I will have to deep into the code to see what are the solutions. do you have idea ?
ScalaDslMongoReadJournal to set the database, if it was not given the configuration (ie. database-resolver was given)
Hi @nleso -
It is not documented in the latest documentation, but there is a legacy approach to supply connection information to the plugin that can be seen in the older documentation. The implementation is in MongoSettings.MongoUri:
val MongoUri: String = Try(config.getString("mongouri")).toOption match {
case Some(uri) => uri
case None => // Use legacy approach
val Urls = config.getStringList("urls").asScala.toList.mkString(",")
val Username = Try(config.getString("username")).toOption
val Password = Try(config.getString("password")).toOption
val DbName = config.getString("db")
(for {
user <- Username
password <- Password
} yield {
s"mongodb://$user:$password@$Urls/$DbName"
}) getOrElse s"mongodb://$Urls/$DbName"
}You can see if the mongouri configuration is not supplied, it falls back to using the legacy fields of urls, username, password, db ... which now that I've typed all this out I see just generates a URI. Hmm
Hi @alokshukla121:matrix.org -
There's no configuration to turn on. But it looks like there may be a configuration setting to turn off.
Looking at: https://github.com/scullxbones/akka-persistence-mongo/blob/master/common/src/main/scala/akka/contrib/persistence/mongodb/MongoDataModel.scala I see your type is considered to be Legacy. Do you have legacy serialization enabled? That may play havoc with tagging.
