I have created a custom type in cassandra:
CREATE TYPE IF NOT EXISTS my_type (
id ascii,
name ascii
);
I use this type in my new table:
CREATE TABLE IF NOT exists person
(
id my_type,
name ascii
);
Is it possible to extend custom type later (add new fields, etc.) - after create database schema? For example when my structure changes and I will need to add some fields into this type, would Cassandra complains about it or it is easy and I could just change custom type?
There is a limited support for schema evolution of the user-defined data types:
You can add new fields to UDT
You can rename the existing field
But you can't do:
Drop existing field from UDT
Change the type of the existing field
See documentation on ALTER TYPE command.
I would like to know how can I search for log messages with a custom properties containing a field named “Main Status” and value “Starting Process”…
how can i do that?
I'm making the assumption that the field is "Main_Status" or "MainStatus". Otherwise you may need to encode it "Main&20%Status", but I'd expect that to be problematic.
If that's acceptable then a query with the field and value would be something like Main_Status:Starting Process*.
You could also verify that the the field exists with something like Main_Status:Starting Process* AND _exists_:Main_Status.
I have a requirement to display a drop down menu for a String type in Hybris Management Console, restricting the value to some specific values.
As suggested in several forums, I tried to create this entry as an enumeration type but characters like '-' are to be allowed in the enumeration values, as this column receives some specific values which comprise of '-'.
How do I solve this issue?
The people advising you probably didn't understand your requirements. As such, an enumeration type is clearly not appropriate in this case. Consider the alternatives. Is there a Map Type available? What other type might allow you to achieve your goal?
Actually, you could use the hybris Enumeration. In hybris Enum Types have a code and a name. The code is the unique representation for this enum and cannot contain a "-". The name however is a localized representation of that value and can include every character your database is able to store. Have a look here:
https://help.hybris.com/6.5.0/hcd/8c895989866910148d6a802f06651702.html
Additionally, hybris enables you to dynamically create new enumeration values, which is kind of nice.
Suppose I have an application whose core data are Projects, Document Sets ("DocSets"), and Documents ("Docs"). Docs are not restricted to any particular content-type; they could be spreadsheets, images, HTML, etc., and can have functions/behaviors other documents don't have. Similarly, I might have multiple kinds of DocSets depending on the type of behavior I need. Maybe this DocSet presents the documents in a flat list, maybe that one associates a status with each document, and has some cool rendering trick based off of status.
The code might look like this if I wasn't using typeclasses:
data Project = Project {
projName :: Text,
projDocSets :: [DocSet]
}
data DocSet = DocSet {
dsName :: Text,
dsDocs :: [Doc]
}
data Doc = Doc {
docTitle :: Text,
docType :: Text,
docContents :: ByteString
}
The problem I see with this is while it allows there to be multiple kinds of Docs (via the docType field), it essentially uses manual type checking, which doesn't feel right (in my head). I could have data constructors for PagedTextDoc, ContinuousTextDoc, SpreadsheetDoc, ImageDoc, etc. That seems like poor modularity to me.
EDIT: My "poor modularity" comment relies on knowledge that wasn't communicated very well. Each Doc has some common behaviors
((de-)serialization, being grouped into a DocSet, a title, rendering,
others as the application evolves), and some unique behaviors
(internal representation in an easy-to-edit format, saving incremental
edits, partial rendering to HTML assuming application is a web app).
Even if that weren't the case, it seems to me like the app would be
more modular if I could just create a new module, define my document
and what you can do with it, and bang, document is now supported. That
way, I define my paginated document over here, my spreadsheet over
there, and the two don't care about each other at all.
Maybe I could use a typeclass for Docs?
data DocSet = DocSet {
dsName :: Text,
dsDocs :: [Doc]
}
class Doc d where
docTitle :: d -> Text
docType :: d -> Text
docContents :: d -> ByteString
The declaration for dsDocs now doesn't typecheck; lists only work for one particular concrete type, vs. any member of a typeclass. The DocSet definitely needs to be able to store/reference multiple kinds of documents.
I've tried to do some searching, but frankly, my Google skills completely fail here. Am I thinking about the data structures correctly? Is the approach with all of (Proj, DocSet, Doc) as a single data constructor each really the best way of handling this, or am I missing something about the way Haskell handles polymorphism?
Well, the class-based proposal doesn't even work. Classes aren't types. You can't have [Doc] if Doc is a class.
The usual approach here is to determine what it is you're modeling, exactly.
Do you want a bunch of things that behave uniformly, and can easily be packaged up together? Then put that behavior into a type. This is usually done by creating a record that holds a function for each kind of behavior you want.
On the other hand, do you have a bunch of things that require very different handling? In that case, put the data into a bunch of types and let the type checker (and exhaustiveness checker) guide you along the way to make sure you're always handling the right thing in the right place.
I don't recommend using classes for this at all. Classes are (mostly) good only for the situation where you can write type-polymorphic code that is meaningful when there is a concrete type, but you don't need to know what the type is. (This is a slight exaggeration, but it's close enough to the truth to use it as a first-approximation heuristic.)
Suppose I have an application whose core data are Projects, Document
Sets ("DocSets"), and Documents ("Docs"). Docs are not restricted to
any particular content-type; they could be spreadsheets, images, HTML,
etc., and can have functions/behaviors other documents don't have.
It sounds like you don't know that types can have multiple constructors (sum types). Instead of your Doc do:
data Doc = PagedTextDoc {docTitle :: Text, docContents :: ByteString}
| SpreadsheetDoc {docTitle :: Text, docContents :: ByteString}
... etc
Similarly, I might have multiple kinds of DocSets depending on the
type of behavior I need. Maybe this DocSet presents the documents in a
flat list, maybe that one associates a status with each document, and
has some cool rendering trick based off of status.
data DocSet = ListDocset Text [Doc] | KoolDocset [(Status, Doc)] | ...etc
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.