For our Spartacus project we need add the subscriptions orders feature.
To do this I think we will have to extend the mapped data model (OrderEntry) present in the default NgRx OOTB store, but I don't think it will be enough.
Which is the proper way to extend the NgRx store data model and related stuff (facade, connector, adapter, ecc.)? Anyone who had deal with similar task here? I searched the documentation thoroughly but found nothing about it.
Any inputs or support would be very appreciated. :-)
Related
We recently introduced GraphQL to our project, I've never used it before, however I like it a lot.
We decided to go with the HotChocolate library for .NET Core and Apollo for client side.
One thing I am not quite sure is about mutations, specifically peforming updates and partial updates with mutations.
I read somewhere that the practice is and that I should stick with creating specific mutation for each update, for instance updateUsername(), updateAddress(), updateCity() all of them should have specific mutation.
Issue with that is that my codebase will grow enormously if I decide to go in that direction, as we are very much data driven, with a lot of tables and columns per table.
Another question is, how to handle nullable properties, I can create a mutation which accepts some input object, but I'll end up with my entity being overwritten and all nullable properties not provided on the calling end will be set to null.
Is there a way to handle this update partially or I should go with specific update mutation for each property I want updated?
I think you understood the best practice around specific mutations wrong. It's less "have one mutation to update one field" and more "have specific mutations that encapsulate actions in your domain". A concrete example would be creating an "addItemToBasket" mutation, instead of having 3 mutations that update the individual tables related to your shopping basket, etc.
GraphQL is very much centered around front-end development, so your mutations should, in general, closely resemble actions a user can perform in your front-end. E.g. your front-end has an "Add to basket" button and your backend has an "addItemToBasket" mutation that resembles the action of placing an item in the user's basket.
If you design your mutations with this in mind, most of the time you shouldn't be having an issue with partial updates, since the mutation knows exactly what's to do and you are not just letting the user of your schema update fields at will.
If for whatever reason you need to have these partial updates, you likely won't get around implementing the patching yourself, unless your data provider supports it. Meaning you will have to have an input object type with nullable properties and your mutation that decides which fields have been changed and changing them using your data provider.
That being said, there's also a proposal for patching types in the Hot Chocolate repository that should simplify the patching part: https://github.com/ChilliCream/hotchocolate/issues/1326
for instance updateUsername(), updateAddress(), updateCity() all of them should have specific mutation.
Issue with that is that my codebase will grow enormously if I decide
to go in that direction, as we are very much data driven, with a lot
of tables and columns per table.
Correct. That's practically impossible to follow that way for more or less big data-driven applications.
Consider how we implement the patching in our API here. Also consider following the discussion about the patching feature in HotChocolate github thread. Hope, that helps!
I'm asking for better understanding.
I am now using firebase and firestore as backend for a project. I know it is highly recommended to use a state management library such as redux or mobx as the single source of truth for application state. However, firestore is realtime database, what are the reasons then, to store the real time data from firestore in a state store prior to using in in the application ?
It doesn't matter what is the backend you use. You don't have to use redux and you shouldn't use it unless you need it and that depends on the application size and architecture. Ask yourself those questions:
Will you be able to lift the state up to a shared parent component
between the children that needs the same slice of state !? If yes,
you don't need redux.
Will you have to pass the state many levels down the component tree
until it becomes annoying because a deeply nested component needs it
!? If yes, you may need redux.
From redux website:
In general, use Redux when you have reasonable amounts of data
changing over time, you need a single source of truth, and you find
that approaches like keeping everything in a top-level React
component's state are no longer sufficient.
You can read more about it here: When should you use redux?
I'm well aware of the standard SilverStripe Data Structure and table/field naming conventions. But how do you integrate SilverStripe with a pre-existing database? Is there any way to map existing tables/fields with a different naming convention to be useable by the SilverStripe ORM and DataObjects? Also, is it possible to use the ORM with two different databases?
In a recent project I had the same issue, and I solved creating views in the SS database over the CRM database, in order to present to SilverStripe the data in the way it likes. Obviously I also created DataObjects mapping the data, and so no dev/build is needed. It's not an easy way to do it, but if you're lucky and the second database logic is similar to SS logic it's a feasible task.
Now I have a CRM that write data into its database with its logic, and SS that reads it through views as if it were its own DataObject.
Good luck :)
I am afraid that, as far as I know, the answer to both questions is no.
I guess the best option would be to write an importer that connects to the old database, fetches the data, and then creates silverstripe objects for it.
If you have to run both systems at a time it will be come trick. The first thing I would consider here would probably be a rest api between the 2 systems, but not sure how well that would work out.
We have a requirement to allow customising our core product and adding additional fields on a per client basis e.g. People entity some client wants to record their favourite colour etc. As far as I know we can't add properties to EF at runtime as it needs classes defined at startup. Each customer has their own database but we are deploying the same solution to all customers with all additional code. We are then detecting which customer they are and running customer specific services etc.
Now the last thing I want is to be forking my project or alternatively adding all fields for all clients. This would seem likely to become a nightmare. Also more often than not the extra fields would only be required in a very limited amount of place. Maybe some reports, couple of screens etc.
I found this article from Jermey Miller http://codebetter.com/jeremymiller/2010/02/16/our-extension-properties-story/ describing how they are adding extension properties and having them go from domain to the web front end.
Has anyone else implemented anything similar using EF? How did it work out? Are there any blogs/samples that anyone has seen? I am not sure if I am searching for the right thing even if someone could tell me the generic name for what we want to do that would help. I'm guessing it is a problem that comes up for other people.
Linked question still requires some forking or implementing all possible extensions in single solution because you are still creating strongly typed extensions upfront (= you know upfront what extensions customer wants). It is not generally extensible solution. If you want generic extensible solution you must leave strongly typed world and describe extensions as data.
You will need to use some metamodel. Your entity classes will contain only properties used by all customers and navigation property to special extension entity (additional table per every extensible entity) where you will be able to put additional properties as name / value pair (you can add other columns like type, validation, etc. if needed).
This will in general moves part of your model from hardcoded scenario to configuration based scenario and your customers will even be allowed to define extensions at runtime (if you implement such feature).
I have a custom implementation of a multi tenant code first system basically SQL Schema Divisions of the tenants. I am using the ToTable method to map the schema correctly on the first call, but as I have read about the model being cached changing the schema on the second call do a different tenant does not work. Is there any ways in EF 4.1 to disable the caching or to rebuild the model every time.. Yes i know this is not great for performance. Thanks for any help..
Although it is an old question, but for all those who face this issue and end up finding this question for a possible solution. Here it goes...
Initially caching could be turned off by setting the "CacheForContextType" property of the ModelBuilder to ‘false’ in the OnModelCreating method. This method is defined in DBContext as virtual and needs to be overridden. But in EF 4.1 this property has been removed, since model creation is an expensive process and the Microsoft team wanted to promote a better pattern. Check this link
It seems like the Build() command on the ModelBuilder is what you're looking for.
modelBuilder.Build().Compile().CreateObjectContext...