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.
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
I would like to create work order using escalation once the asset is moved to some other location (like REPAIR) using move/modify. I do understand that we can trigger CREATEWO however I am not sure on how to set the values on some fields in work order like worktype, workact , etc. Also I am unable to pick the correct record which has performed move modify ( unable to fetch the exact record using ASSETTRANS table).
Let me know if anyone has done this before, thanks in advance!
It sounds like you have an Escalation calling an Action that calls the AppAction CREATEWO. Assuming that's correct..
First, create a Relationship in DB Config between the ASSET object and WORKORDER that will find the most recent work order against this asset. You can look at the NEWWORKORDER relationships on WORKORDER and TICKET as an example. For reference, I will assume you name this relationship MYNEWWORKORDER.
Next, create some Actions against the ASSET object that use MYNEWWORKORDER.<ATTRIBUTENAME> in the Parameter/Attribute field, where <ATTRIBUTENAME> is the name of the attribute (e.g. WORKTYPE) you want to supply a value for in the Value field.
Once that is done, create an Action of type Action Group where CREATEWO is the first member and the Actions you just made are the succeeding members.
Finally, update the Escalation to call your new Action Group instead of the numbered one that the Escalation application created for you.
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.
I have an non-persistent attribute (SITEID) on my WOCHANGE object that originates from the parent object, WORKORDER. For some particular reason, this attribute has a few problems that I've never really seen with other attributes before.
Based on various configurations I have tried in an attempt to remedy the issue, here are the main issues:
It doesn't trigger the WOCHANGE to save when changed.
In addition to the value not being saved, I can change the value on one record, go to another and the value persists on the different record.
The field is readonly unless I define it to have an inputmode of DEFAULT. This is odd to me, because not defining inputmode usually implies default behavior (NOT readonly).
Here are the definitions for the SITEID attribute on both the WORKORDER
and WOCHANGE objects.
SITEID also uses a TABLE domain belonging to the SITE table.
Are there any attribute rules being applied from other sources that I should be checking?
That workorder field class on there may not be desired and may be messing with things, like setting the field to read-only. Site Id is commonly a read-only field, especially when the record is no longer a new record. Because of that, the logic to make that field read-only could be buried deeper in the Maximo business logic than just that field class. You are working with a field that has a lot of special meaning in Maximo, you are likely going to stumble into many built-in business rules.
Since non-persistent fields are not saved in the database (they are in memory fields only), I don't believe they trigger the flag for a record to be saved. What would be saved? Nothing in the database (a save) is to be changed yet.
Your screenshot however shows the field as persistent. Is WOCHANGE a view? I can't recall and no longer have the resources to check.
I am facing an issue with extended attributes on a document (trying to extend a document table). I created the original table’s PK (FDOC_NBR) in the extended table and linked the two via a foreignKey of the customized original table’s ojb entry (as an “extension” reference-descriptor). I created the bo and dd for the extension and customized the original document’s dd to add the new attributes. On the extended BO itself I also added members (with setters and getters) for the 2 new columns + for the PK column of documentNumber. I also added the new attributes to the documet’s jsp. The pertinent module definition was already extended to include custom dd, ojb, etc. files.
Indeed, when opening the document the new fields are shown- however, when trying to submit the document (regardless of doing anything with the new fields) I get an error-
Error Details: OJB operation; SQL []; ORA-01400: cannot insert NULL
into ("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR") ; nested
exception is java.sql.SQLIntegrityConstraintViolationException:
ORA-01400: cannot insert NULL into
("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR")
Seems like somehow the system tries to insert a value of NULL into the extension’s PK field, instead of the actual document number. Trying to debug this, in the action’s route method and all the way down to DocumentDaoOjb.save (which is as far down as I can go) I see the document with the real doc number is passed on, so the problem seems to be purely with ojb trying to set this number to the extension table.
Does anyone have any experience with extended attributes on documents that could help shed some light on this?
KFS is using the KNS, and in the Kuali Nervous System, the primary key on the extended attributes object must be set through manual intervention.
In this case, it looks as if you're adding an extended attribute to a transactional document, the Travel Arranger document (TAA), which simplifies things. Basically, you'll need to extend org.kuali.kfs.module.tem.document.TravelArrangerDocument and override prepareForSave to set the document number there (it may be set already since prepareForSave should be called several times during the routing process, but there's no real harm from overwriting that information as the base document's number will remain the same).
Hope this helps!