cancel
Showing results for 
Search instead for 
Did you mean: 

Backoffice - Using different datasource to persist data in cassandra DB

Former Member
0 Kudos

Hi,

We are building a separate application for managing delivery slots which has intensive write operations. So instead of using oracle DB which we are using for application, we plan to use Cassandra that works best for intense write operations.

The front end will still be backoffice for configuring the delivery slots. However, the need is to store the data in cassandra instead of oracle. How can we plug in a different data source for specific objects in hybris.

Assume we have a grid like layout which allows configuring slots like:

Monday 6-8 9-11 12-4 Tuesday 7-9 10-12 -1-5 .... ....

Each slot will have a capacity too.

We won't create hybris item types but in back office want to show them as attributes and when user enters the values, on clicking save, we want to persist it in Cassandra.

Any thoughts on how we can use multiple data sources in back office?

Thanks.

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hello Saurabh. Try to combine complex solution: You can declare own item type which extends GenericItem and consist of dynamic attributes and is deployed into own table. Your DynamicAttributeHandler with Interceptors must be responsible for getting/setting values from external datasource. Also your item type should contain some attributes which can be used for mapping items between Oracle and Cassandra. Yes, in this case you cannot avoid totally manipulations with Oracle but it helps to decrease load on this database because only the minimal information will be stored in Oracle

Former Member
0 Kudos

hi Saurabh, We've seen quite a few grocery projects implementing this feature, I haven't heard of any of those considering using an external storage. Given the fact that the delivery time slot is typically registered once per order I doubt whether you're getting a (really) high amount of writes. Its probably comparable with the number or orders that will be created (not even similar to the number of order entries). Given the complexity you're going to face to connect a new datasource i'd recommended to reconsider the architecture and, in case of doubts, do some performance testing upfront to test the system.

Cheers, Tobias

Former Member
0 Kudos

Hi Tobias, Thanks for your response. In terms of slot reservation you are right that number of slot reservations will be equal to number of orders being placed. However, the additional bit will be when store managers will be updating the slot capacity frequently which will mean more writes on DB. Do you think it will still be able to scale up? We will have around 4000 stores pan india to start with.

former_member625836
Active Contributor
0 Kudos

Hi Saurabh,

I don't really get what you try to achieve with those slots. If you are not planning to create separate item type, then what type of values would it be? Will it still be complex type or just primitive values? If complex, then I assume that you will manage them totally by yourself? If so, then you would have to write your own object strategy (implement and register com.hybris.cockpitng.dataaccess.facades.object.ObjectFacadeStrategy bean). You may also think about implementing your own save handler in configurable-flow (you would have to remove ootb save button and your own: see Invoking Custom Logic section).

Cheers, Jacek

Former Member
0 Kudos

Thanks for reply jacek. It is a grocery implementation where there is a slot management feature involved where end customers can pick delivery slots when they want order to be delivered. It will be a custom item type and will have a relationship like this : Slot has Slot Range (1:n).

The intention is to save the data in cassandra or some other data source because we will have heavy writes on data and if we use oracle DB which we are using application wide, we may not be able to scale up. So I wanted to know if backoffice allows saving data for a specific item type in a different database.