Spring Data MongoDB
  1. Spring Data MongoDB
  2. DATAMONGO-525

Customizable naming strategy for auto mapping domain object to database names

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
      None

      Description

      As a developer, I would like to be able to set a naming strategy that can automatically convert my field and entity names inside my domain object to the format expected of the database. This will avoid unnecessary coupling of database details (i.e. the name of the table or column) to the domain object and avoid having to annotate every field in the domain object. This sort of functionality is similar to Hibernate's NamingStrategy interface (https://docs.jboss.org/hibernate/orm/4.0/javadocs/org/hibernate/cfg/NamingStrategy.html) except it would work for any type of database (in our case MongoDB).

      @Document(collection = "my_account")
      public class MyAccount {
      	@Id
      	private ObjectId id;
      
      	private String name;
      
      	@Field("customer_id")
      	private ObjectId customerId;
      }
      

      In this example, the database document and fields expect the name to be lowercase with underscores but our domain object uses standard Java camelCase. If there was a naming strategy that automatically converted all camelCase fields or document names to underscores then we could avoid the @Field annotation and specifying the collection name. If any field needed a custom name that differed from the naming strategy, it could still be overridden with @Field.

        Activity

        Hide
        Bilguun Bayarmagnai added a comment -

        I think multi-tenancy is very important and growing need. If one could define collection-per-tenant strategy, that would be great. Is there any way to implement this for the moment. Please take a look at this question on stackoverflow http://stackoverflow.com/questions/15728413/collection-based-multi-tenancy-in-spring-data-mongo

        Show
        Bilguun Bayarmagnai added a comment - I think multi-tenancy is very important and growing need. If one could define collection-per-tenant strategy, that would be great. Is there any way to implement this for the moment. Please take a look at this question on stackoverflow http://stackoverflow.com/questions/15728413/collection-based-multi-tenancy-in-spring-data-mongo
        Hide
        Oliver Gierke added a comment -

        The @Document's collection attribute supports SpEL expressions so that you can theretically simply declare a Spring bean (e.g. fooBar) in your application context that exposes a getTenantPrefix() method looking up some thread bound prefix. You could then annotate you entities with

        @Document(collection = "#{fooBar.getTenantPrefix()}_persons")
        

        Would that work for you?

        Show
        Oliver Gierke added a comment - The @Document 's collection attribute supports SpEL expressions so that you can theretically simply declare a Spring bean (e.g. fooBar ) in your application context that exposes a getTenantPrefix() method looking up some thread bound prefix. You could then annotate you entities with @Document(collection = "#{fooBar.getTenantPrefix()}_persons" ) Would that work for you?
        Hide
        Bilguun Bayarmagnai added a comment -

        Thanks Oliver! Very great. This is what I've been looking for. But you mentioned 'theretically', which scares me a little bit. So how reliable is this approach in your opinion? Eager fetching and queries against associated domains will work properly?
        And one more thing: Maybe, this spEL capability on collection should be mentioned in the reference. This could help many others. This strategy might help with locality etc.
        Again thank you very much. Your help changed our choice on technology

        Show
        Bilguun Bayarmagnai added a comment - Thanks Oliver! Very great. This is what I've been looking for. But you mentioned 'theretically', which scares me a little bit. So how reliable is this approach in your opinion? Eager fetching and queries against associated domains will work properly? And one more thing: Maybe, this spEL capability on collection should be mentioned in the reference. This could help many others. This strategy might help with locality etc. Again thank you very much. Your help changed our choice on technology

          People

          • Assignee:
            Oliver Gierke
            Reporter:
            Steven Sheehy
          • Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: