Create better strategy for storing content on filesystem about spring-content HOT 6 CLOSED

Hi @bilak,

You are exactly on point with this issue, @paulcwarren and I both spoke about this awhile back. I created a story for us to take a look next week. Depending on the outcome a PR might be just what we need!

Have a great weekend!

from spring-content.

Hi Lukas,

Firstly, thanks for the inputs thus far. Very helpful. We think we know how we should achieve this so we thought we would run it past you.

We probably want to add a PlacementStrategy bean with a getLocation method that, given an ID, returns a path (probably a String, but maybe a URI?).

This path can then be used with an expanded ResourceTemplate service (currently AbstractResourceTemplate) that exposes Spring Resource objects and their streams.

DefaultXYZRepositoryImpl's can use this PlacementStrategy bean together with the ResourceTemplate to implement their ContentStore functionality. I imagine at least SC FS and SC S3 will want to make use of this. We need to look into Mongo's GridFS - it may well be capable of support this too - and if it does we would probably support placement there too. On the flip-side though it probably doesn't make any sense for SC JPA as that just stores BLOBs in a table but that is of less concern to us as most content management services would likely not choose to use this storage method.

The other reason for creating an expanded ResourceTemplate (and for keeping the placement strategy separate from it) is to enable application's that don't want full CM functionality to also do content access (in the same developer friendly way) thus increasing the appeal of Spring Content.

This probably represents quite a bit of work, but definitely both required and worthwhile. We will try pick this up this week/early next.

from spring-content.

Hi Paul,

interesting ideas. I don't know much about S3 and Mongo but I've got another ideas for FS. From current implementation it looks like when I want new FS content store (CS) then I need to create new entity/spring repository/content repository for it. There could be an option where all contents will be stored in one entity/content store and somehow partitioned. Let's create annotation @FileSystemPartition (or maybe some name which fits better) for entity field which will split contents in partitions on FS (e.g. /filesystemroot/partition1 /filesystemroot/partition2). For this there also need to be some @ContentId generator which will guarantee the correct "sequence" id generation.

interface PartitionContentIdGenerator {
   Object generateIdForPartition(Object partition);
}

Maybe parameter and return type should be of Long type.

I was working on something similar today, but was interrupted by other project. If I have time during next days I will try to create some branch and post my ideas.

from spring-content.

Atm the root of the content store is configured globally but I think you are right it should be configurable on a per content repository basis and that could very well be done via an annotation on the content repository interface, or something like that. Sounds like a different issue to me though so I created this issue to keep it separate from from this placement strategies one.

from spring-content.

Hi guys,
try to look at this commit and tell me what do you think about it. It isn't finished yet, but I want to listen from you if that could be way how the FS can perform. I must implement somehow the configuration for SimplePartitionDefinition or generally for PartitionDefinition and I'm thinking about DB config or application.yml config. What do you think?

from spring-content.

@bilak we have implemented a pluggable storage strategy with a UUID-based implementation for SC Filesystem and SC S3. We believe this will resolve this issue for you.

You can find more information in the filesystem docs. See 3.3.1. Storage Model.

from spring-content.