I have run into a little roadblock in regards to joining mantle entities. I would like to have a single depicting fields from two mantle entities, but am unsuccessful in joining them. Specifically, I have linked a list of party relationships (as contacts) to a single partyId (vendor), with the goal to make a vendor contacts page. However I am unable to link that form-list with the PartyContactMech and ContactMech entities (in order to display email and phone number in the same form-list). More generally, my question is how can one map lists to each other the same way one can map a list to a single object (using entity-find-one and value-field does not work when tried with entity-find)?
There is no need to make a view-entity (join entities) to do that. Simply do a query on the PartyRelationship entity in the main 'actions' part of your screen specifying the toParty (vendor). Then in your Form-List, use 'row-actions' to query the PartyContactMech and so on for each fromPartyId (contact) entry that the previous query returned. Also have a look at the PartyViewEntities file in Mantle USL. There are some helpful view-enties already defined for you there such as PartyToAndRelationship, PartyFromAndRelationship etc. Also note that entity-find-one returns a single "map" (value-field) as it queries on the PK. Whereas entity-find returns a list of maps (list). They are separate query types. If I understand your question correctly.
Related
We're really enjoying using the capabilities offered by React-Admin.
We're using <ReferenceArrayInput> to allow filtering of a <List> by Country. The drop-down contains all countries in the database.
But, we'd like it to just contain the countries that relate to the current set of filtered records.
So, in the context of the React-Admin demo, if we've filtered for Returned, then the Customer drop-down would only contain customers who have returned items (see below). This would make a real-difference in finding the records of interest.
Our current plan is to (somehow) handle this in our <DataProvider>. But, is there are more ReactAdmin friendly way of doing this?
So you want to build dependent filters, which is not a native feature of react-admin - and a complex beast to tame.
First, doing so in the dataProvider will not work, because you'll only have the data of the first page of results. A record in a following page may have another value for your array input.
You could implement that logic in a custom Input component instead. This component can wrap the original <ReferenceArrayInput> and read the current ListContext to get the current data and filter value (https://marmelab.com/react-admin/useListContext.html), then alter the array of possible values using the filter prop (https://marmelab.com/react-admin/ReferenceArrayInput.html#filter).
I would like to join the user object and project permission object to see how many users have been assigned to a project, for audit purpose. I don't see a common field with common values (email address or first name/last name) between these objects. I used Excel plugin to retrieve two separate data sheet and unable to map them. Any thoughts on this on how to do this?
You're probably seeing something similar to the following when you query on ProjectPermissions:
In this situation, the default User object selected from the "Columns" picker in the query dialog, gives you the User's DisplayName, which doesn't unambiguously map to a Rally UserID.
Note, however, that you can add dot-notation sub-fields of Objects manually by typing them into the Columns field. In the following example, I've included User.Username and User.LastLoginDate as additional fields I want to show on the Permissions report:
Of course, you could also just include User.Username, and run a second query on the User object with all fields selected, and do a join in Excel.
One note of caution - if you have many users (say 1,000), and a lot of projects, (say 1,000, which is not uncommon in large Rally subscriptions), querying directly against the ProjectPermissions endpoint can rapidly result in total results that number on the order of 10^6. This will probably time out in an Excel query.
The Rally User Management: User Permissions Summary script works around this by querying Permissions in a loop on a user-by-user basis. It's slow, but it returns results without timeouts. Certainly not as convenient as Excel either - you need to install Ruby 1.9.2+ and the rally_api gem to get it working.
I saw an example of "QUERYING FOR TASKS", but it only returns the id and name of the tasks, I would like to get more information about tasks (for example created_at, completed, due_on, followers, etc) by querying them with API.
(I work for Asana)
See the section on input/output options in the docs: https://asana.com/developers/documentation/getting-started/input-output-options
By default, objects that are subobjects or that are returned from queries are output in "compact" form, which is usually just ID and name. If you want more detail for those objects, you can specify specific fields to include in the output using the opt_fields parameter. You can get all available fields on an object by "expanding" them with opt_expand. So if you are querying for tasks and want full records instead of compact ones, use opt_expand=.
I'm building a chatroom application, and I want to keep track of which users are currently in the chatroom. However, I can't just store this array of users (or maybe a list would be better) in a field in one of my records in the Chatroom table.
Obviously one of the SQL data types is not an array, which leads me to this issue: what is the best way to fake/mock array functionality in a SQL database?
It seems there are 3 options:
1: Store the list/array of users as a string separated by commas, and just do some parsing when I want to get it back to an array
2: Since the max amount of users is allowed to be 10, just have 10 extra fields on each Chatroom record representing the users who are currently there
3: Have a new table Userchats, which has two fields, a reference to the chatroom, and a user name
I dunno, which is the best? I'm also open to other options. I'm also using Rails, which seems irrelevant here, but may be of interest.
Option 3 is the best. This is how you do it, in a relational schema. It is also the most flexible and future-proof option.
It can grow easier in width (extra columns say, a date joined, a channel status, a timestamp last talked) and length (extra rows when you decide there now can be 15 users in a room instead of 10).
The proper way to do this is to add an extra table representing an instance of a user being in a chatroom. In most cases, this is probably what you will want to do, since it gives you more flexibility in the types of queries you can do (for instance: list all chatrooms a particular user is in, find the average number of people in each chatroom, etc.) You would just need to add a new table - something like chat_room_users, with a chat_room_id, and a user_id.
If you're deadset on not adding an extra table, then Rails (or more specifically ActiveRecord), does have some functionality to store data structures like arrays in a SQL column. Just set up your column as a string or text type in a Rails migration, and add:
serialize :users
You can then use this column as a normal Ruby array / object, and ActiveRecord will automatically serialize / deserialize this object as you work with it. Keep in mind that's there are a lot of tradeoffs with this approach - you will never be able to query what users are in a particular room using SQL and will instead need to pull all data down to Ruby before working with it.
I've got a table in my database storing items:
Items
-------
ItemID
Name
...
Etc
and a separate table storing the PK of two different items from the first table. I want to be able to list the one item, and then any number of related items. I've tried searching for examples but haven't found much surprisingly...
RelatedItems
------------
ItemID
RelatedItemID
If I have four products, whose IDs are 1, 2, 3 and 4... and 1 is related to 2 and 3 I might have data that looks like this:
ItemID RelatedItemID
1 2
1 3
4 1
I am then modeling them in the Entity Framework Designer, and the designer automatically adds an association from the Items table to itself (many to many). The designer also adds two navigation properties, if I use the first property on Item #1 I get all items where Item #1 is in the first column, and if I use the second property I get all the items where Item #1 is in the second column.
I however just want to have one navigation property where I can say Items.RelatedItems and it returns all the items that the above two properties would when combined. I know I can join the two results after the fact but I can't help to think I'm doing something wrong and there is a better way.
Hopefully this is all clear enough.
It sounds like SQL schemas just aren't very good at modeling the concept you're looking for. The schema you've chosen would work well if you want to establish a directional relationship (item A is related to item B, but item B may or may not be related to item A). If you were looking for a grouping-style relationship (Items A and B are in the same group), I can think of a different approach you'd use. But I can't think of a good way to model an inherently bi-directional relationship using a traditional relational database.
Some workarounds might be to use a View that joins the two results, or to use triggers to make sure that every mapping from A to B has a corresponding mapping from B to A, so that both of the properties always return the same objects.
If you have an instance of an Item, call it item, then the following will give you the related items...
item.RelatedItems.Select(ri => ri.Item);
Your RelatedItems property on item (ie the first navigation property you mentioned) will be a collection of RelatedItem objects, each of which has two navigation properties of its own, one of which will be named Item and will be a link to the related item.
Note that this is air code, as I'm not in front of anything I can test this on right now, but I think this will do what you want.
If you want to make it simpler, you can write an extension method to wrap up the Select(), something like this...
public static IEnumerable<Item> RelItems(this Item item) {
return item.RelatedItems.Select(ri => ri.Item);
}
Then you could just do...
item.RelItems();
Note that I couldn't name the extension method RelatedItems, as that would clash with the navigation property that EF would have created for the second table. That's perhaps not a good name for that tables, as it's not the actual items, rather the IDs of the items. Either way, the above code should work.