I have a requirement where my dynamodb table has many attributes, and i need all of them in the projection expression except one or two columns which i dont need in response. (I am scanning the table).
Is there a way how can i define this in ProjectionExpression (all except this one column).
I have seen examples where ProjectionExpression only takes what all "is required" and not the other way.
As per the documentation, this is not possible:
ProjectionExpression - A string that identifies one or more attributes
to retrieve from the table. These attributes can include scalars,
sets, or elements of a JSON document. The attributes in the expression
must be separated by commas. If no attribute names are specified, then
all attributes will be returned.
Here is a link to help you better undestand what goes underneath the ProjectionExpression: https://medium.com/pageup-tech/dynamodb-and-projection-expressions-why-c08c40243195
Related
I'm somewhat confused as to what the proper secondary index would look like for DynamoDB.
I have Name, Date, Period, Data attributes and want an index that lets me efficiently lookup by Name, Date, and Period.
I also want to efficiently lookup all Names for a given Date.
I tried setting my secondary index partition key to Name since I want those to be grouped together on nodes. And added attribute projections for Date and Period. Is this the way to go?
Every single access pattern needs to be enumerated and you need to think about its corresponding retrieval mechanism. Your base table provides one access mechanism. You can use GSIs for the additional mechanisms.
The base table and each GSI provide a PK and SK for you to use. The PK must be an individual value (sometimes composed of several values concatenated together with a separator like hash). The SK can be a sortable value, used either as a value or range. Those are the tools at your disposal.
"All names for a given date" might use a GSI where the date is the PK and the names are the SK.
At reasonable scale you don't have to think too much about hot partitions. At high scale (more than 1,000 write units needed per second) you'll have to think harder before putting everything under a single date PK for the GSI.
I was wondering if anyone has every had experience with breaking a string up in quicksight and using certain aspects of the string. My example is a data set that returns tags like this "animals|funny|dog-park" I have used "split(tags,'|',1)" but then all that gets returned is the first part(animals). I have also tried a combination of ifelse->locate->split with no luck. Is there a way to split these tags to where they are all usable (animals) & (funny) or (funny) & (dog-park), etc.? Say the article associated will then be broken up into one tag but also another separately? I know this will end up being a calculated field most likely. Thank you in advance!
Since QuickSight does not support any form of nested fields (including objects and list) in analysis, you need to normalise this into separate rows before feeding the data to QuickSight.
Otherwise, if you leave it as is, you would be limited to filtering using string contains and doing string lookup in calculated fields - nevertheless you would not be able to use these tags as categories (such as in colours field well of visuals).
Is there a way to retrieve just the attribute names and ignore the attribute values of a single item in DynamoDB? I know I can use the GetItem call and discard the attribute values on the client, but my attribute values can be quite large.
My use case is that I have a potentially huge number of attributes names that match this format foo-bar-YYYY-MM-DD. The values that each attribute stores can be quite large too - around 100KB each. My goal is to have a script that deletes all attributes that are beyond a few weeks old (based on the foo-bar-YYYY-MM-DD attribute name).
Retrieving this huge amount of attribute value for each attribute name via the getItem call is unnecessary for me. It would be amazing if I can just fetch all the attribute keys of a single item without having to deal with excess memory concerns.
Using AWS Cloudsearch, I need to query 2 separate fields for the same value using a structured (compound) query e.g.
(and (or name:'john smith') (or curr_addr:'123 someplace' other_addr:'123 someplace'))
This query works, but I'm wondering if it's necessary to repeat the value for each field that I want to search against. Is there some way to specify the value only once e.g. curr_addr+other_addr:'123 someplace'
That is the correct way to structure your compound query. From the AWS documentation, you'll see that they structure their example query the same way:
(and title:'star' (or actors:'Harrison Ford' actors:'William Shatner')(not actors:'Zachary Quinto'))
From Constructing Compound Queries
You may be able to get around this by listing the more repetitive fields in the query options (q.options), and then specify the field for the rest of the fields. The fields list is sort of a fallback for when you don't specify which field you are searching in a compound query. So if you list the address fields there, and then only specify the name field in your query, you may get close to the behavior you're looking for.
Query options
q.options={fields: ['curr_addr','other_addr']}
Query
(and (or name:'john smith') (or '123 someplace'))
But this approach would only work for one set of repetitive fields, so it's not a silver bullet by any means.
From Search API Reference (see q.options => fields)
I asked a question similar to this previously (How to use RecId as a foreign key in a form) but would like to explore it a bit further in a more complex scenario.
Replacement keys work great when you have indexes set up and allow duplicates set to no, but they don't seem to work at all with multiple-field indexes or when allow duplicates is set to yes.
Is there way, programmatically, to replace a foreign key in a grid with a translated value without using replacement keys? I tried writing a display method to override the field, but some odd behavior resulted--fields moving around in the grid, and the display method being unaware of which row to use, thus all values in the entire column were the same.
Table A: Bob:1, Sally:1, Sue:3
Table B: 1:Apples, 2:Apples, 3:Oranges
The "people" are tied to their favorite "foods" by the food RecId, refererenced in the People table. Assume there is additional data in other columns that make these records unique, so consolidating "1:Apples" and "2:Apples" is not possible.
It seems there should be a way to write a display method to overwrite a field value in a grid. Any suggestions? Sample code?
Thanks
Firstly, surrogate FK replacement does (or at least should) work with composite keys (e.g., {First Name, Last Name}).
Secondly, you state that there is "additonal data in other columns" that make these records unique...Then why aren't these columns being combined with the food's name to form an alternate key? The data model seems incorrect (or at least some metadata isn't being made consistent with the conditions you've stated)
Thirdly, any Field Group can be chosen as the ReplacementFieldGroup on a Reference Group control. That alone will allow you to do basically whatever you want. That said, I would strongly encourage you to use an alternate key as your replacement field group whenever possible due to the semantics of surrogate FK replacement.
Flow:
1) User types a value(s) into reference group.
2) User's tabs out.
3) User's typed value(s) are used to look up a record in the related table.
4a) If the user's typed in value(s) are uniquely mapped to a record that record is chosen, else,
4b) If the user's typed in values are not unique a lookup is presented to allow the user to pick which record they "meant". Note that the lookup must therefore present a collection of uniquely identifiable records so that the user knows which record to pick (if the records all look the same in the lookup then they'll have no idea what in the hell they should pick.)
5) Upon successful resolution of the typed values, the record is set back on the source form.
Given this flow, it is obvious that steps 3-5 will be broken if there is no unique index (key) on the table. (How is the user supposed to specify a unique reference to the record if the record has no means of being uniquely identified (assuming you don't want to display RecId to the user)???)
In the exceptional case that you decide that you still want to use a non-unique index as your replacement field group you must implement resolveReference and lookupReference to provide the user a unique resolution/lookup experience (to handle steps 3-5 in the above flow). Note: The common use case for this is wanting to effectively eliminate non-selective fields from being displayed in Reference Group and instead letting some outer context or mode implicitly set that value. E.g., if the alternate key was {Size, Color}, one could potentially make "Color" a global form context--perhaps by having the user pick a color at the top of the form--and only have the user enter Size into Reference Group...The Color could then be implicitly added back via the resolveReference and lookupReference overrides.