About composite entities, like CART (#color:color #object:object). Why when I am using the following response: You choosen $cart, sometimes the response is object + color not color + object as choosen in the entitie CART?
This behavior is intended as the composite entity is a dictionary of entities and a dictionary is an unordered data structure. The data values are retrieved by keys and not by order. Hence, in composite entities order cannot be preserved. To get the response in order you have to use individual entities to retrieve the values.
Related
In Pony ORM, it is possible to ‘automatically’ create a many-to-many relationship. For example, from the documentation (for version 0.6, emphasis mine):
In order to create many-to-many relationship you need to define both
ends of the relationship as Set attributes:
class Product(db.Entity):
tags = Set("Tag")
class Tag(db.Entity):
products = Set(Product)
In order to implement this relationship in the database, Pony will
create an intermediate table. This is a well known solution which
allows you to have many-to-many relationships in relational databases.
Is it possible to create an extra attribute (column) in the automatically created intermediate table, so not just foreign keys to ‘Product’ and ‘Tag’, but, e.g., also a timestamp?
If yes, how?
If not, I guess I'll have to create the intermediate table explicitly. Can I in that case still use the nice Set-attribute definition (perhaps to the intermediate table, indicating the attribute of interest)?
Currently it is necessary to define explicit entity, like this:
class Product(db.Entity):
name = Required(str)
tags = Set("ProductTag")
class Tag(db.Entity):
name = Required(str, unique=True)
products = Set("ProductTag")
class ProductTag(db.Entity):
product = Required(Product)
tag = Required(Tag)
PrimaryKey(product, tag)
timestamp = Required(datetime, default=datetime.now)
Pony does not support virtual Set attributes like through in Django, but we plan to add them in the future. Right now you need to work with intermediate table explicitly.
Adding a tag to a product
p1 = Product[1]
tag1 = Tag.get(name='smartphones')
p1.tags.create(tag=tag1)
# or:
ProductTag(product=p1, tag=tag1)
Removing a tag from a product:
ProductTag[p1, tag1].delete()
Checking if a product has a specific tag:
ProductTag.get(product=p1, tag=tag1) is not None
Also, Pony support the concept of attribute lifting. That means that in Pony any collection attribute has all attributes of its items. The value of a such collection attribute is a collection of all values for individual items. For example, in order to get all tags for specific product, you can write:
p1.tags.tag
The p1.tags expression returns a collection of ProductTag items. Each ProductTag object has tag property which points to a specific tag object. So p1.tags.tag returns a collection of all Tag objects linked with a specific Product object.
It is possible to use attribute lifting inside queries. For example, in order to found all products with the tag smartphones you can write the following query:
select(p for p in Product if 'smartphones' in p.tags.tag.name)
Here, p.tags is a colection of ProductTag objects, p.tags.tag is a collection of Tag objects, and p.tags.tag.name is a collection of tag names. The query above is a syntactic sugar for the following query:
select(p for p in Product if 'smartphones' in select(item.tag.name for item in p.tags))
Also, the query can be rewritten as:
select(pt.product for pt in ProductTag if pt.tag.name == 'smartphones')
In a JSF page I have to display the data from an entity.
This entity has some int fields which cannot be displayed directly but need to be translated into a descriptive string.
Between them some can have a limited number of values, others have lots of possible values (such as a wordlwide Country_ID) and deserve a table on the Db with the association (ID, description).
This latter case can easily be solved navigating via relationship from the original entity to the entity corresponding to the dictionary table (ID, description) but I don't want to introduce new entities just to solve translations form ID to description.
Besides another integer field has special needs: the hundred thousand number should be changed with a letter according to a rule such as 100015 -> A00015, 301023 -> C01023.
Initially I put the translation code inside the entity itself but I know the great limits and drawbacks of this solution.
Then I created a singletone (EntityTranslator) with all the methods to translate the different fields. For cases where the field values are a lot I put them inside a table which is loaded from the singletone and transformed in a TreeMap, otherwise the descriptions are in arrays inside the class.
In the ManagedBean I wrote a getter for EntityTranslator and inside the jsf I use quite long el statements like the following:
#{myManagedBean.entityTranslator.translateCountryID(myManagedBean.selectedEntity.countryID)}
I think the problem is quite general and I'm looking for a standard way to solve it but, as already stated, I don't want to create new 'stupid' entities only to associate an ID to a description, I think it is overkill.
Another possibility is the use of converters Object(Integer) <-> String but I'm more comfortable in having all the translation needs for an Entity inside the same class.
Your question boils down to the following simple line:
How can I display a field different from id of my entity in my view and how can I morph an integer field into something more meaningful.
The answer is that it depends on a situation.
If you solely want to input/output data, you don't need id at all apart from the possible view parameter like ?id=12345. In this case you can input/output anything you want in your view: the id is always there.
If you want to create a new entity most possibly you have a way of generating ids via JPA, or database, or elsehow besides the direct input from the user. In this situation you don't need to mess with ids as well.
If you want to use information on other entities like show user a dropdown box with e.g. a list of countries, you always have the option to separate label (let it be name) and value (let it be id), or even have a unique not null column containing the country name in your database table that will serve as a natural identifier. If you'd like to get data from the user using an input text field you always can create a converter that will do the job of transforming user input strings to actual entity objects.
Regarding the transformation of your integers, you've actually got several choices: the first one is to attach a converter for these fields that will roughly do 301023 -> C01023 and C01023 -> 301023 transformations, the second one is to write a custom EL function and the third one is to prepare the right model beforehand / do the transformations on-the-fly.
I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.
Hashtable iHashtable=new Hashtable();
iHashtable.put("Name", "Jhon");
iHashtable.put("Address","India");
Enumeration iEnumeration=iHashtable.keys();
while(iEnumeration.hasMoreElements())
{
Object iresult1=iEnumeration.nextElement();
String iresult2=(String) iHashtable.get(iresult1);
System.out.println(iresult1);
System.out.println(iresult2);
My problem is I want to put the value at LWUIT table dynamically using the HashTable key and value,here is iresult1 and iresult2,using the key and value I want to create the LWUIT table where the value will be shown in the following form.
Name Jhon
Address India
please help me with the source code because i am new in J2me Application.please remember don't hardcore the key and value ,we get the value after parsing.
You can't do that since the JSON data isn't tabular but rather a hierarchy of nested hashtables and vectors based on the response from the server.
You can show the JSON data as a tree though by implementing the tree model interface, its not trivial but not too hard. You just need to return key objects for the keys (instead of strings) so they will allow including a reference to the value element.
Why does curl http://localhost:5984/blog/_design/comments/_view/total_num?group=true return
{"rows":[
{"key":"sum","value":23},
]}
and not
{"rows":[
{"sum": 23},
]}
There are a couple different reasons.
As Tim McNamara points out, having the key as the member name in the result row means that keys are limited to strings because of the rules of JSON. This way allows people to have view keys of any JSON type.
As Alex Koshelev points out, if we allowed keys as object member names in the view row then the key and value would not be directly addressable. This means that you would have to investigate each and every row to figure out what the key was.
A second aspect of the namespace issue is that a key could conflict with any metadata that may be included in that row. For instance with include_docs=true or the included docid member for non-reduced view output.
Alternatively, if you would like to reformat the output to suit your needs, you can use a _list function to change each row to your liking.
In addition to Alex and Tim's responses:
The view's keys may not be unique, i.e. the same key may have been emitted for multiple documents or even multiple times for a single document.
The view's rows are ordered by key. JSON's object type is an "unordered set of name/value pairs". Many languages, including JavaScript, do not define the order of keys in a mapping. A list is therefore a better representation for something with order.
Allows for null objects as keys.
Each row can have additional data, such as document data (doc) for include_docs=true queries.