I m using (String, Arraylist of String) as the key value pair in gemfire caching.Is there any method to just add or delete a particular value from the value list without getting the entire list and add/delete and publishing the list again?!
You can create wrapper object to keep list. This wrapper object can implement delta interface. Using this you can add/delete field from list. See if this helps.
GemFire serializes the value when storing, and has various complex configurations to control the type and level of serialization.
Therefore, when you're updating a value in the value, what's happening is that the serialized value is being streamed to the client and then you're changing it and then re-serializing the changed value and streaming it to the server which is then storing it.
If you want to just update a value in the ArrayList on the server side itself, then you have to create a server-side listener and add that class to the server's classpath so you can manage the serialization/deserialization more finely.
Alternatively, you probably need to change your data model so that the ArrayList value is more like a Map, and is flattened to a secondary region colocated with the primary region, etc.
Related
https://rally1.rallydev.com/slm/webservice/v2.0/typedefinition/<defect_id>/Attributes
After hitting the specified url we get the fields for the specified defect id but in order to fetch the allowed values for dropdown fields we have to hit another api.
Is there any other way through which we can get all the fields with the allowed values instead of the reference to the allowed values in a single api call?
Unfortunately with the introduction of WSAPI version 2.0, the ability to load sub collections of data within the initial request was removed. This was done in order to improve performance as it was previously possible to request too large a set of data and have a significant impact on the performance of the system.
So the only way to fetch the lists of allowed values for fields is to loop through the list of defect attributes, grab the necessary endpoint url from the _ref value and load it from there.
It could be worth saving the references to these attribute IDs as they shouldn't change as long as the fields aren't removed from the object model.
I am working with Endeca 6.4.1 and have many auto-generated dimensions present in my pipeline (mapped using Dev-studio), the application's indexing is CAS-less. So only FCM is creating Dimensions and assigning dValIds. I am using Endeca SEO, so the dVal Id directly reflects in my URL, and if an auto-gen dimension's value's Id changes, a link to that navigation State is lost.
I have a flat file as the dimension's source, for example
product.feature|neon finish
What I want is that, if the value some day changes to Neon-finish or Neon color, the dValId that was assigned to neon finish should be transferred to the new value. I can keep a custom mapping of the change to track that neon finish has been changed to a new value.
Is there any way to achieve this, may be by using some manipulators?
Please share your thoughts.
There are two basic ways to do this:
1) Update the state files when you change a dimension value (APPDIR/data/state/autogen_dimensions.xml ). This would most likely be a manual process.
2) A more robust but complex solution is to change the dimension values to be some ID number and use a synonym for the display name. Then the display name can change without a change to the id number. This may require some serious changes to your pipeline.
Good luck
So, many times before when I needed to add a property to an entity, I created a new version of xdatamodel file and performed lightweight migration, that automatically added this property to all already existing NSManagedObjects.
But now i need no only to add property, but also to fill it with a value, that can be calculated using another existing property.(Ex: I have an entity User with property "name", and now I need to add a property "hashname" = [user.name base64],so that all my existing users have this filled property)
So, is there a way to do it using migration? (I know that it's possible simply select all users without hashname and fill it manyally after lightweigt migration, but i want to know if migration technology provided by apple can do it for me)
You have to do it "manually". The only automatic filling of a property is with a default value, but that would not be dynamic.
You don't need to actually add calculated properties to the model. Just create an NSManagedObject subclass that includes this property and calculates it from its other attribues.
I am attempting to create a new Case object using the REST API but need to find out how to format the JSON body to pass in nested SObjects.
It's not apparent in the Docs, and I can't seem to find any examples. Anyone have any pointers or have done this before?
The SF web UI uses a text lookup field to set the (related) Contact and Account, and I need to figure out how to either bypass the need for a lookup or embed the SObjects of the related records in the JSON.
[{"message":"The value provided for foreign key reference Contact is not a nested SObject","errorCode":"INVALID_FIELD"}]
Figured it out by simply setting the AccountId and ContactId attributes on the new Case object.
I also haven't seen any documentation about this, but if you look at the object metadata returned by the REST API for any standard object, it seems that the suffix 'Id' is appended to any field of type "reference". For example, Case has OwnerId, LastModifiedById, CreatedById, etc. This suffix is not present in the field names displayed in the browser interface. The WSDL for the SOAP API includes both the ID as a simple element of type "ID", as well as a complex child element for nesting the actual record.
Under one UnitOfWork (session) I may call CreateCriteria twice. My first call is to populate a grid for data editing. Let's say the data has been edited and flushed (saved) to the database and the grid is still open. After the data is edited, I may call CreateCriteria a second time to retrieve a list of objects that are validated and found in error.
Lets say ObjectA was retrieved by both calls to session.CreateCriteria. It was edited in the grid but found in error within the second list.
The first question would be: Considering first level cache, is ObjectA--that was retrieved from the second call to CreateCriteri--represent the one retrieved from the first call? or, better yet, did NHibernate "detect and reuse" ObjectA from the first call assuming the keys did not change?
To my final point in question: I want to edit ObjectA which was found in error, and let's say it was brought up in a ListBox. Therefore, I want to highlight that object, call session.Get()(key) in order to retrieve it from cache, then bring up a change form to change ObjectA's properties. Which object am I changing? The one from the first call to CreateCriteria or the second call? Are they the same?
Thank you in advance.
Second level cache
Take a look at http://ayende.com/Blog/archive/2006/07/24/DeepDivingIntoNHibernateTheSecondLevelCache.aspx and http://www.javalobby.org/java/forums/t48846.html
From the former:
The second level cache does not hold
entities, but collections of values
So, with caching setup properly, NHibernate will be able to recreate your object without having to get the actual values from the database. In other words, the object will be created the same as when it wasn't in cache, except that since the values are cached, NHibernate won't actually query the database since it already knows what's in there.
I'm not quite sure what you mean by "validation" and "found in error". Are you validating before insert? Typically my entities are validated before the insert/update and won't actually be inserted/updated if invalid.
Validation aside, what I think you're asking is that if you:
save something
do a flush
retrieve an item (from a new session) with the same key as the one saved in step 1
will you be retrieving the same reference to the object you saved in step 1(?). And the answer is no since NHibernate does not cache the OBJECT but rather the values so it can create a new entity populated with the cached values (instead of actually performing a DB query).
However, does that really matter? If you overload Equals such that equality of 2 entities are based on their ID, then finding the same (not reference equal, but same) item in a grid (or a hash of any kind) should be a snap.
First level cache
I didn't realize you were talking about 1st level cache. 1st level cache works as an identity map and does cache the instance of the object. Therefore, if you do 2 selects from the db based on the same ID, you will retrieve the same instance of the object.