I am new to Hybris and was following the Commerce trail given in Hybris wiki. I can see that they perform "Update" under "Platform" tag. What does this operation do ?
From the above link. for people who do not have wiki access or if page moves.
Update
During an update, type system definitions are modified to match the new type system definition in the items.xml files.
First and foremost, the update mechanism makes sure that all data that existed in the system before the update is still accessible after the update.
Therefore:
•Update preserves the table name, to which a type was mapped, even if it was changed in items.xml
•Update preserves the column name, to which an attribute was mapped, even if it was changed in items.xml
•Update preserves the column type for an attribute, even if it was changed in items.xml
•Update does not drop any tables and columns
•Update does not delete any item data, including type instances and type system data (composed types etc.)
•Update drops and recreate indices, if they are added or changed in items.xml
•Update does NOT change the attribute from optional to mandatory, even if it was changed in items.xml
This is what the process looks like:
1.The type system definitions from all extensions items.xml files are read in.
2.The hybris Commerce Suite type system in the database is modified according to the type definitions of all extensions items.xml files.
A. Adding newly defined types to the type system definition in the database.
Type definitions and attribute definitions that are not part of the type system definition in the database are added.
B. Modifying existing types to match the type system definition in the database.
Type definitions and attribute definitions that are changed compared to the type system definition in the database are modified.
C. Again, like in the init process, the old update logic (prior to hybris Commerce Suite 5.1) iterates through extensions and uses extension manager methods to create and modify types. Whereas, in the new update (since hybris Commerce Suite 5.1), ddl and dml scripts are also generated here.
D. Update then continues with creating essential and project data, optionally, if selected.
As you have access to the hybris wiki you should check the following URL: https://wiki.hybris.com/display/release5/Initializing+and+Updating+the+hybris+Commerce+Suite
Here you will find everything about the initialize and update functionality in the hAC of hybris.
Related
I had an attribute in an itemtype defined to be String. I changed the type of the attribute to Enumeration. However I am trying to update the existing values with an INSERT_UPDATE to one of the existing enum values and getting the following exception:
java.sql.SQLException: Fail to convert to internal representation
How to go about in this case?
The problem is the same as your previous question. (Redefining data type in items.xml in Hybris is not wise to change the type of an attribute. I would recommend to create a new field (with different name and use it for future) or just restore a previous copy of your DB.
I had this kind of error only when I don't update the system via HAC.
Update the running system!
hac > Platform > Update
System update won't change the dataType.
For Local: you can do an initialize with the new sample data.(for that particular Enum change).
For higher environments: You have to directly operate on the database. Alter the database column data first with the corresponding ENUM's PK value and then change the type of the database column to LONG
By default, jhipster create entity with id as long/int. I would like to use "String" for id. How to do that?
There are two steps:
Of course the property type in the Java class must be changed to String (and also update the getter and setter for that property).
Then create a Liquibase changeset that modifies the data type to String. See: http://www.liquibase.org/documentation/changes/modify_data_type.html
If there are foreign keys that depend on this id, then makes it a bit more complicated because the fk's will need to be dropped and recreated after the columns have been changed to String.
Take a look at src/main/resources/config/liquibase/changelog to see how to set up a changeset consistent with the jhipster. I usually copy an existing changeset, give it a new file name so that it is the last file in the directory (so you can see a chronological sequence of changes), and update the changeset id.
Then, the changeset must also be added to src/main/resources/config/liquibase/master.xml so that it is activated on the next app start.
I have a Core Data model with a single transformable attribute. I also have this attribute use a custom NSValueTransformer, setup in the model properly.
When I use mogenerator to generate/update my machine and human files, the machine files for the entity containing this attribute always type the attribute to NSObject. In order for Core Data to use my custom value transformer, this type needs to be the type the transformer understands. Right now, I manually do this in the human file by redefining the property with the proper type. This does the job and gets the transformer working. However, I end up with several compile warnings regarding redefinition of the attribute.
One of the more recent releases of mogenerator specified in the release notes that transformable attributes are now supported. However, I haven't found any example syntax to enable this feature.
This should be better documented.
To set your generated attributes's type, select your desired attribute in the modeler and switch to the User Info tab. Then create a new element with a key of attributeValueClassName and a value of whatever you'd like.
Here's a screenshot:
I wound up modifying the source from a publically posted POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, which is a custom field definition for cascading drop downs. The modifications were to allow parent-child list boxes where a user can multiselect for filtering and selecting the values to be written back to a SharePoint list.
I got the parent-child cascading behavior working, but the save operation only takes the default Content Type value.
I changed the base type for the custom field control from "SPFieldText" to "SPFieldMultiChoice", along with changing the FLD_TYPES field definition values from: "Text" to "MultiChoice"
Steps Explained:
1. The custom field is created which is derived from ‘SPFieldMultiChoice’ class. The custom field allows multiple values to be selected.
2. The Field created using above custom field is added to custom content type created from GUI derived from ‘Document’ Content type.
3. The custom content type is added to the document library.
4. The document is uploaded and custom content type is selected and tagged to document.
A. The correct content type gets tagged with correct metadata if type of document is .xls,.doc,.txt etc
B. The default content type i.e. ‘Document Content Type’ gets tagged if type of document is .xlsx, .docx.
Issue Summary – Point#B: is an issue as correct content type is not tagged and default content type gets tagged if type of uploaded document is .xlsx or .docx.
However same content type , same custom field works if type of document is .xls or .doc.
Appreciate your inputs in this regard.
Thanks for taking the time to read through my post.
Cheers, ~Poonam
Not sure why this is happening, it might be a good idea to notify Microsoft of this behavior. The difference between .doc and .docx you describe is very, very strange. Could you try setting the content type in an itemeventreceiver, to force the ContentType or ContentTypeId field of the item to reflect the correct content type explicitly.
i.e.
item["ContentTypeId"] = new ContentTypeId("0x010100your_id_plus_the_part_added_by_list");
the_part_added_by_list is the extra guid that is added when a ctype is added to a list
this is because ctypes in a list are basically children of the actual ctype you added
i.e. 0x010100 YOURGUID 00 LIST SPECIFIC GUID,
you can get this full id using a tool like Stramit CAMLViewer, or progr. by looping through the SPLIst's ContentTypes collection.
(my guess would be to do this in the ItemUpdating / ItemUpdated event to see if there is a difference in ctype during those calls)
When beginning to develop against SharePoint I did not fully understand all the ins and outs initially. I created a list definition (for a document library) and associated various custom actions to it. Unfortunately, I used the following for the list definition itself:
<ListTemplate...
...
Type="101"
...
And to register the CustomActions against the list:
<CustomAction...
...
RegistrationType="List"
RegistrationId="101"
...
Of course, this means that the custom actions are visible for all document libraries where the feature is activated which is undesirable behaviour. Also, there are lots of these document libraries that have been created from the above list definition in production.
What is the best way to fix this problem? My assumption is that I somehow need to change the "Type" attribute of the already existing lists, but I do not know how to do that. Can it be done via some direct SQL manipulation perhaps? Or is there a better way?
Note: I can see that the AllLists table has a column tp_ServerTemplate, is that the right thing to change?
Modifying the SharePoint database is completely unsupported by Microsoft. Please do not do this on production!
Another option is to create a content type and associate the custom action with that. You may need to write a simple console application to iterate through your existing document libraries and add the content type so it is available for use. The existing documents that you'd like the custom action to apply to would need their content types changed as well.
From some quick initial testing it does look like changing the AllLists table does the trick.
So steps to resolve:
1) Change List Definition Type attribute to be a unique value (for example 11000)
2) Change the CustomAction RegistrationId attributes to be the same (11000)
3) Update the tp_servertemplate column in the AllLists table to be the new template Type (11000) for all the relevant lists.