Although I've developed some services with Liferay ServiceBuilder, I'm not quite sure I understand the point of using the attributes:
userId
companyId
groupId
Note that these attributes are available through the PortalRequest.
Following the basic tutorials, you are instructed to create these attributes for every entity, and take care to set them on 'add' functions. But thinking of it, I've not ever seen any tutorial or referenced code where these attributes are used on data retrieval (Finder methods, dynamic queries, or custom queries either)
So what's the point on keeping this information ?
Are these attributes used automatically somehow under some convention or scope ? Something like, the Liferay's default Finders using them when they are available through the PortalRequest ?
Or is it up to the developer to use them on every Select, E.g. are all the single-parameter Finders practically useless on multi-instance Portals (since the companyId attribute should be used on every Finder method) ?
Or is it just a good practice to keep this structure for database extendability, auditing, indexing or something else I'm totally missing ?
These attributes are necessary when you use your entities for example on staging environment. The groupId specifies to which environment the entity belongs to. Meaning of userId is obvious and as for companyId it is the site identifier. So IMHO these attributes are quite important when you have multiple sites on one portal, when you have staging env. enabled etc..
Suppose you have a new table and you want to set UserId in your table then it is necessary but otherwise I don't think these attributes are neccessary.
I have created service builder
<entity name="FaoEsalesCustomer" local-service="true" remote-service="false" table="fao_esalecustomer">
<!-- PK fields -->
<column name="esaleCustomerId" type="long" primary="true" />
<!-- Audit fields -->
<column name="createdBy" type="long" />
<column name="createdOn" type="Date" />
<column name="modifiedBy" type="long" />
<column name="modifiedOn" type="Date" />
<!-- Other fields -->
<column name="customerName" type="String" />
<column name="address" type="String" />
<column name="ph" type="Integer" />
<column name="categoryId" type="long" />
<column name="categoryName" type="String" />
<column name="quantity" type="Double" />
<column name="price" type="Double" />
</entity>
Related
When you create a work item such as Bug in Azure devops, the values that you would see in the drop down of say Reason field would depend on the value you select for State field. For e.g. see these screenshots (Template Agile, no customizations)
Then if you change the state, the allowed values change as shown
To make matters more confusing, these are just few of the values that are returned by the documented REST API
The given API returns
"defaultValue": null,
"allowedValues": [
"Verified",
"Not fixed",
"Test Failed",
"As Designed",
"Cannot Reproduce",
"Copied to Backlog",
"Deferred",
"Duplicate",
"Fixed and verified",
"Obsolete",
"Fixed",
"Investigation Complete",
"Approved",
"Investigate",
"Resolved in error",
"Reactivated",
"Regression",
"Build Failure",
"New"
],
"helpText": "The reason why the bug is in the current state",
"alwaysRequired": false,
"dependentFields": [
{
"referenceName": "System.State",
"name": "State",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/System.State"
},
{
"referenceName": "Microsoft.VSTS.Common.ResolvedReason",
"name": "Resolved Reason",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/Microsoft.VSTS.Common.ResolvedReason"
}
],
"referenceName": "System.Reason",
"name": "Reason",
"url": "https://dev.azure.com/{project}/{templateid}/_apis/wit/fields/System.Reason"
},
I am trying to figure out the right API or set of APIs that help demystify when to show what in the combo boxes, when to mark them read-only and when to let the user edit them.
The Resolved Reason Field is further interesting. For most parts it seems to simply copy the value from the Reason field, however the Rules API (see below) does not indicate this behaviour. It looks like what the Rules API returns does not match the behaviour that this field exhibits.
There is a concept of Rules mentioned in the REST API here - https://learn.microsoft.com/en-us/rest/api/azure/devops/processes/rules/get?view=azure-devops-rest-5.1#processrule
However this does not seem to give rules which specifically control "allowedValues" for fields based on value of another field as I explained above.
Question:
Is there an API that can give a comprehensive set of rules for fields on a work item types including their allowedValues? For e.g. the Reason or Resolved Reason field depending on the choice of State field as shown above?
Is there an API that can give a comprehensive set of rules for fields
on a work item types including their allowedValues? For e.g. the
Reason or Resolved Reason field depending on the choice of State field
as shown above?
First of all, I need to say, no, there is no such REST API to get the Reason value which depending on the State filed chosen. Since these are all not be documented, the best way for us to verify it is using the Fiddler trace(Fiddler can record all internet data between web application and internet).
[As example, here I will use Bug work item to show that.]
First, clear all the records in Fiddler => open the Bug work item in Azure Devops => press F12 in Fiddler to start record the data.
Change the work item state in Azure Devops(Note: just change, do not save it. "Save" belong to another operation). Then go Fiddler to see its internet records:
You will see that there only 2 event API, and these API are only used to post the action sign but not operate it. See the request body of first POST Event API:
You can see that it just used to post a sign about the State field has changed. That's why I say that there's no API to get the Reason value which depending on the State filed chosen, because our develop team did not use the script with API to achieve that.
Now, you should be very confusing that who is this action message to be sent to? Since the Reason field value listed is not controlled by the api, then who is in control?
The answer is XML process template.
In Azure Devops, the WIT are all controlled by XML template. You can find all rules such as the Reason field value listed depend on the State field changed, copy the value from the Reason field and etc.
I have uploaded the Bug.xml of process template into my github, you can refer to that code to analysis it: Agile-process/Bug.xml .
For the Reason field value listed depend on the State field
changed.
<FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
<LISTITEM value="Cannot Reproduce" />
<LISTITEM value="Deferred" />
<LISTITEM value="Duplicate" />
<LISTITEM value="Fixed" />
<LISTITEM value="Fixed and verified" />
<LISTITEM value="Obsolete" />
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
<HELPTEXT>The reason why the bug was resolved</HELPTEXT>
</FIELD>
These are the xml code which control the Resolved Reason listed. I believe that you have got its logic. The message of event API we got from fiddler are get by the relevant WIT *.xml. Then the corresponding operation will be trigger and acted.
For copy the value from the Reason field.
<TRANSITION from="New" to="Resolved">
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin" />
</ACTIONS>
<REASONS>
<DEFAULTREASON value="Fixed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Fixed" />
<ALLOWEDVALUES>
<LISTITEM value="Fixed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</DEFAULTREASON>
<REASON value="Deferred">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Deferred" />
<ALLOWEDVALUES>
<LISTITEM value="Deferred" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Duplicate">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Duplicate" />
<ALLOWEDVALUES>
<LISTITEM value="Duplicate" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="As Designed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="As Designed" />
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Cannot Reproduce">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Cannot Reproduce" />
<ALLOWEDVALUES>
<LISTITEM value="Cannot Reproduce" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Obsolete">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Obsolete" />
<ALLOWEDVALUES>
<LISTITEM value="Obsolete" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Copied to Backlog">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Copied to Backlog" />
<ALLOWEDVALUES>
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<COPY from="field" field="System.CreatedBy" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
</FIELDS>
</TRANSITION>
This just a short section which about the copy value from the Reason field from the xml file of Bug work item.
In fact, you can find all process rules from these XML file which could not get with API(Note: I just mean the default process rule). If you want, I can share the completed XML files of process in my github.
Hope this could help you more clearly:-)
Is there an API that can give a comprehensive set of rules for fields
on a work item types including the allowedValues of say Reason field
depending on the choice of State field?
For this issue , you can use Rules - List api to get it .
GET https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workItemTypes/{witRefName}/rules?api-version=5.1-preview.2
I test with postman , the figure below is the result returned by my test.
By searching for keywords, we can get the rules of allowed values for Reason field depending on the choice of State field.
The processId parameter required in the api can be obtained through this rest api.
Hope this helps.
In DB2 LUW it is recommended that tables, indexes and "long objects" (ie LOBs) should be placed in separate tablespaces. Our existing SQL scripts have lines like this:
CREATE TABLE "APPLICATIONTABLE"(
APPLICATIONID INTEGER NOT NULL,
APPLICATIONNAME VARCHAR(30) NOT NULL
)IN USERSPACE1 INDEX IN USERSPACE2 LONG IN USERSPACE3;
In a changeset we can specifiy a tablespace:
<createTable tableName="APPLICATIONTABLE" tablespace="${tablespace.data}">
<column name="APPLICATIONID" type="NUMBER(4, 0)">
<constraints nullable="false"/>
</column>
<column name="APPLICATIONNAME" type="VARCHAR(30)">
<constraints nullable="false"/>
</column>
</createTable>
But not, as far as I can see, DB2's multiple tablespaces. Is there any way to do this?
You could use a sql change which liquibase doc describes as:
The ‘sql’ tag allows you to specify whatever sql you want. It is useful for complex changes that aren’t supported through Liquibase’s automated refactoring tags and to work around bugs and limitations of Liquibase. The SQL contained in the sql tag can be multi-line.
It looks like this (copied from the liquibase doc):
<changeSet author="liquibase-docs" id="sql-example">
<sql dbms="h2, oracle"
endDelimiter="\nGO"
splitStatements="true"
stripComments="true">insert into person (name) values ('Bob')
<comment>What about Bob?</comment>
</sql>
</changeSet>
EDIT:
Just saw another option after reading this answer.
You could use the modifySql tag. Maybe leave out tablespace info and just append it like this (untested code - just a suggestion):
<createTable tableName="APPLICATIONTABLE">
<column name="APPLICATIONID" type="NUMBER(4, 0)">
<constraints nullable="false"/>
</column>
<column name="APPLICATIONNAME" type="VARCHAR(30)">
<constraints nullable="false"/>
</column>
<modifySql dbms="db2">
<append value=" IN USERSPACE1 INDEX IN USERSPACE2 LONG IN USERSPACE3"/>
</modifySql>
</createTable>
This is something that is supported by the Datical extensions to Liquibase, but not in Liquibase itself.
I know this is 6 years old, but I thought I'd post this as another possible solution. From their site they give the following as example
<changeSet id="2" author="liquibase">
<createTable catalogName="department2"
remarks="A String"
schemaName="public"
tableName="person"
tablespace="${tablespace}">
<column name="address" type="varchar(255)"/>
</createTable>
</changeSet>
Then define the tablespace name on the command line. If you had multiple you could provide multiple -D options
liquibase -Dtablespace='tablespaceQA' update
I am using EF in .NET V4.0 in Visual Basic (VS2010) with SQL Compact Edition 4.0. We are building a set of simple forms to maintain some tables. One table 'Companies' is linked to 2 other tables (People,CalibrationInfo) with Companies as the parent table. The Entity Type Definition is:
<EntityType Name="Company">
<Documentation>
<Summary>Provides a list of Companies and shipping addresses.</Summary>
</Documentation>
<Key>
<PropertyRef Name="CompanyID" />
</Key>
<Property Name="CompanyID" Type="Int32" Nullable="false" annotation:StoreGeneratedPattern="Identity" />
<Property Name="Name" Type="String" MaxLength="100" Unicode="true" FixedLength="false" Nullable="false" />
<Property Name="Address1" Type="String" MaxLength="100" Unicode="true" FixedLength="false" />
<Property Name="Address2" Type="String" MaxLength="100" Unicode="true" FixedLength="false" />
<Property Name="Address3" Type="String" MaxLength="100" Unicode="true" FixedLength="false" />
<Property Name="Telephone" Type="String" MaxLength="30" FixedLength="false" Unicode="true" />
<Property Name="PrimaryContactID" Type="Int32" a:GetterAccess="Public" xmlns:a="http://schemas.microsoft.com/ado/2006/04/codegeneration" a:SetterAccess="Public" Nullable="true" >
<Documentation>
<Summary>Optional Primary Contact ID for the primary contact for this company.</Summary>
</Documentation>
</Property>
<Property Name="Disabled" Type="Boolean" Nullable="false" DefaultValue="false" />
<NavigationProperty Name="Calibrations" Relationship="NWCUDataStoreModel.FK_CalibrationInfo_Company" FromRole="Companies" ToRole="CalibrationInfo" />
<NavigationProperty Name="PrimaryContact" Relationship="NWCUDataStoreModel.FK_Company_PrimaryContact" FromRole="Company" ToRole="Person" />
</EntityType>
The form uses a binding source set to the Company set in the context:
bsCompanies = ctx.Companies.OrderBy("it.Name")
The Binding Source is linked to a Navigation Bar. Pressing the BindingNavigatorAddNewItem button gets a new record created. I enter only the company name tab to the next field and press the Save button. The link to the Primary Contact is set to nothing so there are no other relationships for this record. The Save button executes the following:
RowsSaved = ctx.SaveChanges()
This generates the InvalidOperationException. The Inner exception is:
AcceptChanges cannot continue because the object's key values conflict with another object...
There are no other records in the database with the name set to 'Test'. The exception indicates that the record was saved, but was unable to accept the changes. The record is still marked as Added. Calling ctx.AcceptChanges after this error generates an exception.
If I were doing this directly in code, instead of with BindingSource on a form, it would essentially look like this:
dim company as New Company
company.Name="Test"
company.PrimaryContactID = nothing
ctx.Companies.Add(company)
ctx.Save
I have looked at other examples of this on multipe sites, and have applied any fixes I could find, including setting the PrimaryContact id directly to a the correct Person record ID and setting the PrimaryContact to Nothing. Nothing makes any difference.
I have also deleted the three tables from the model and then reloaded them. No difference.
I have used this same code with no problems in SQL Server, but almost nothing seems to work with SQL Compact edition V4.0. You would think it should not be so difficult to store a single record into a table. If we have to go back to data sets, I have a lot of recoding to do.
Any suggestions or insights appreciated.
Thanks, Neil
BTW, the answer to this was to use Nuget to download Entity Framework 6.0, Entity Framework SQL Server Compact and Microsoft SQL Server Compact 4.0. I then downloaded the EF Framework 5 DB Generator .tt file as the EF 6 version does not work in Visual Studio 2010. You do this from the Add Code Generation menu item, and select Online Templates->EF 5 DBContext Generator... Finally, I modified the file using this Microsoft article: Databinding with WinForms. After that, things started to work. EF 4.0 does not work with SQL Server Compact, out of the box, without the changes described above. Using the ObservableListSource class described in the article also helped with parent-child relationships on forms, which did not work until I switched to this class.
I want to define an entity like below:
<entity name="Book" local-service="true" remote-service="true">
<column name="bookId" type="long" primary="true" />
<column name="bookPrice" type="BigDecimal" />
</entity>
my liferay is 6.0.6.
how can it possible to create new type like BigDecimal or other types in liferay service builder?
I'm trying to populate a smartgwt calendar using data form a server obtained using a datasource. Unfortunately the examples in showcase only use client only test data, where one has to create an array of calendar events first. Can anyone give an example of how to do this directly from a rest datastore for example.
Thanks.
Yes, I had trouble tracking down an example too. I eventually figured it out by looking at the samples. It seems like the Calendar doesn't care about the type of the objects used by the datasource, but rather that they provide properties of name, startDate, endDate, and description. (Note that startDate and endDate should be defined as "datetime" in your ds.xml, or all of the events will be full-day events.) Here an example ds.xml (based on the sample for Google App Engine modified with a calendar object):
<DataSource
ID="Appointment_DataSource"
serverConstructor="com.isomorphic.jpa.GAEJPADataSource"
beanClassName="com.smartgwt.sample.server.Appointment"
>
<fields>
<field name="eventID" type="text" hidden="true" primaryKey="true" />
<field name="name" type="text" title="Name" required="true" />
<field name="startDate" type="datetime" title="Start Date" required="true" />
<field name="endDate" type="datetime" title="End Date" required="true" />
<field name="description" type="text" title="Description" />
</fields>
</DataSource>