Should Change Tracking Proxies work if I use a Database First model?
After creating the model with the database first designer, though navigational properties are marked virtual, other properties are not.
If I edit the classes so that the properties are virtual (and of course public, not sealed, use ICollection where needed and remove initializing of navigators from the classes constructor), this will get overwritten if I ever update the model from the database while within the designer.
And, if I make all (what I believe are) the necessary changes to allow for Change Tracking Proxies, when I test with "x is IEntityWithChangeTracker" it still returns false.
So, either I'm really doing something wrong or I'm doing something that wasn't meant to be. I hope it's the former.
EF6.x uses System.Data.Entity.Core.Objects.DataClasses for its IEntityWithChangeTracker. If you use this version of IEntityWithChangeTracker, it will work. Using System.Data.Objects.DataClasses.IEntityWithChangeTracker was my problem here.
Related
I am working on the SAP Commerce (formally known as Hybris) ecommerice system.
The Warehousing extension is being added to a B2B site. Upon adding it, On the Stock Level item the Invoice Event collection is visable on the admin tab. An ATP Formula has been set on the Base Store. The stock is now displayed on the PDP. In an OTB site I have seen an OTB instance adjust the stock levels accordingly upon completing an order, but that is not happening on the local dev instance. The question is why?
Is the impression correct that some facade within the warehousing extension is called during the order-processing process? If so, how exactly is that wired up? There doesn't seem to be any relationship to the warehousing extension and any other code.
UPDATE 1:
Here is an example of the question: After adding a new product populator to the custom facade, a few entries are added to the *-spring.xml file, one of them being adding the populator to the configurablePopulatorModification. Finally the option needs to be added to the ProductOptions list in the controller. Then the populator is called when that controller is called.
In this example the connection between the controller and the popular is clear, once it is understood how things are wired up. There is a connection to the ProductOptions in the custom core extension, custom facade extension, and custom accelerator. Once someone knows how this is "wired up" it can be easily duplicated.
What I am trying to understand is this: The warehousing extension has been added to the localextensions.xml, but there is NO reference to any aspect of that anywhere else in the system, AT ALL. Somehow some extension between the storefront accelerator and the platform code has to know about the new functionality found in the warehousing extension so that it is called. How?????
UPDATE 2:
After adding the warehousing extension, there are new attributes added to existing itemTypes that show up in Backoffice. It is my understanding that this is the concept which Modifying Lists and Maps in Spring Context explains.
The issue I am having problems understanding is how the business logic within the warehousing extension is being called to modify the stock levels. My best guess is that the function doing the change is WarehousingStockLevelFacade.createStockLevelAdjustements(...). I have searched high and low for where createStockLevelAdjustements(...) is called and it is ONLY called in the warehousingwebservices.
I am at a total loss on how exactly any of the facades wihtin warehousingfacades or warehousingwebservices is being called by
Hmmm, your text contains more than one question I think. So I try to answer each part of them separately.
In an OTB site I have seen an OTB instance adjust the stock levels accordingly upon completing an order, but that is not happening on the local dev instance
There should be no difference on the systems. You should always look, that you have the same configuration on each system. Normally the 'config' folder here is the part where you define the configuration. From system to system there can be small difference. But for example, the 'localextensions.xml' shold always be the same.
Is the impression correct that some facade within the warehousing extension is called during the order-processing process?
No. You define your extensions in the 'localextensions.xml' and than the new parts are on any system. Have you done an 'UPDATE' on each system, so that the new types are also imported in the type system and the database?
So overall. You define your extensions. And than hybris includes all needed extensions automatically. You can see this, when you start the server, which extensions are loaded.
UPDATE 1
I think, now I got your point. I try to stay in common and not to specify on the 'warehouse' extension. Hybris has some funtionalities how to modify code 'afterwards'. Here are some useful links
Modifying Spring beans afterwards
Extension Dependency
Also have a look left in the navigation about the 'Extnsion Concept'. Maybe some points will than be clear.
So in your example, think what happens is: first new attributes in the *-items.xml, than there will be a 'modifiyPopulatorList' bean somewhere.
UPDATE 2
I don't know the 'warehousing' extension. But I think there must be a part that overwrites the 'normal' beans with the 'warehousing' beans. Something like:
<bean id="stockLevelBean" ...>
<property name="normalProvider" ref="normalProvider"/>
</bean>
<bean id="stockLevelBean" ...>
<property name="warehousingProvider" ref="warehousingProvider"/>
</bean>
So i have a table which lists some appointments. These appointments belong to an event. The goal here is to list all the appointments and get the information of the event that they belong to.
So far everything works fine until i try to get the information of the event. I get an object which looks like this:
Now if i use something like this : {appointment.event.title} it will give back NULL.
That means that it doesnt access the properties. In TYPO3 v8 it works perfectly, but not in TYPO3 v9.
If i activate the <f:debug>{appointment}</f:debug> and get the whole object as debugged, then this {appointment.event.title} works! I can get the title.
The question now is what have changed since TYPO3 8 and can not access these properties anymore and how can i regain access?
In use: TYPO3 v9
Mode: Composer
Best regards,
I found the solution to my problem.
Thanks to #Claus Due i visited my Model to see if the getters und setters are there. They were there BUT before my getter, the #lazy parameter was present. After i removed, everything worked as it should.
Thank you!
Probably one of the following is true:
You forgot to add a getter method for the property you try to access and you are confusing the output of f:debug with what is actually gettable from the object. The debug ViewHelper outputs also protected properties.
You constructed the model object with __call or __get so you are affected by https://github.com/TYPO3/Fluid/pull/438 which is solved but not yet released (current Fluid version is 2.6.0, patch will be included in next version).
You don't say which TYPO3 version you use, nor if you are using composer, so it's hard to tell if your versions of Fluid are the same - they should be, since both TYPO3 v8 and TYPO3 v9 use the same external Fluid library.
The solution in either case is to add proper getter methods to your domain model object and always remember that the output of f:debug does not 100% correspond to what you can actually access: f:debug will for example not show virtual getter methods that don't have a property associated with it.
Which table in Liferay stores the predefined values given for a structure.
Also is there a facility in Liferay to populate these values dynamically using webservices?
The API used to be JournalStructureService, however, as the documentation states, this has been replaced with the Dynamic Data Display API, which, for example, you can find under DDMStructureService in version 6.2.
This gives you a hint where to find the underlying data, however, you don't want to manually write to the database. You do want to use the API to change values. Trust me. Consider the database to be an implementation detail and leave it alone - if nothing else to make your next upgrade experience easier. You should never change any values in the database manually without knowing exactly what you're doing. And, trust me, the keyword here is "exactly", and you'll fail to know all the possible side effects. Don't touch it.
As said #Olaf, depends on Liferay version you will need to use the JournalStructureService or the DDMStructureService. So, if you want to use the Liferay Service by web api you have two options the Axis api where you can obtain WSDL (domain:port/api/axis) or you can use the Json api (domain:port/api/axis). In many cases you are going to need a token to use this services.
The generated designer.cs properties are private by default (at least without manual tweaking of generated code). This makes coding against something like a UITableViewCell feel much different than if I were doing this in Objective-C.
The popular way in the case of UIxxxViewCells, at least from what I can tell, is for the UIxxxViewDataSource to populate the IBOutlet properties, and that the cell should only be responsible for anything related to drawing/rendering the view.
With Xamarin.iOS, we are unable to access these properties from the data source, and instead are required to provide additional setter methods to populate the cell. In this way, the cell is responsible for setting it's own properties.
Is this just "The .NET way" of doing things?
It's so that we don't break encapsulation by default.
The outlets belong to the object they're on, it should be able to choose whether they're able to be modified from the outside. The fact that they're properties is an implementation detail of the Xamarin.iOS outlets system - you should think of them as private fields.
If you wish to expose them, you can create properties that do so - preferably read-only.
It was probably done that way because that's how the other GUI designers in MonoDevelop worked at the time (still do). Auto-generated bindings to the native controls used by the user-designed control for toolkits like Gtk# are also created as private.
I'm not sure if other UI designers for .NET work (I've never used Visual Studio to develop GUI apps using Windows.Forms or WPF).
Feel free to file a feature request on https://bugzilla.xamarin.com to make them public - I'll gladly implement it, I think it probably makes more sense for them to be public. I haven't changed it mostly because no one has expressed that they wanted it be any other way.
In EF4, I would generate my model from the DB. Then I would extend the classes using partials. This allowed me to regenerate from the DB without losing my code.
In EF5, when generating from the model, it creates a .cs file for every item in DB. I actually like this a lot more except, I am not sure what the best way to extend the objects is. If I write my changes right in the MyObj.cs file, I will lose them if I have to re-generate the model. I guess I chould create file MyObjPartial.cs and make the class partial there... thought?
~S
You should follow the same pattern as before, by using a partial class. This is basically the same with all auto-generated file types and EF is not any different. You want to make sure you don't lose the changes when you regenerate the file.
Partial classes are also great in this example as a separation concept, that way you have the stuff that's important to your application separate to the stuff that's important for the running of Entity Framework