I'm using a framework which is based spring-data-redis, and the framework was using #RedisHash to set value the redis key uses. Is there a way to override the value set in #RedisHash?
I'm tring to use KeyspaceSettings to do that, but it seems not working. I've noticed the official documentation says "#RedisHash has the highest priority", is it the truth?
However, the annotated keyspace supersedes any other configuration.
Yes, you can choose the name of the hash adding a name parameter like this:
#RedisHash("name_hash")
Related
In previous versions of API Platform you've been able to define the path for an operation with route parameters in the standard Symfony style, i.e. /resource/{id}/{parameter}
In the newest version of API Platform (v3) the configuration of these paths seems to have changed so that you need to create a Link() metadata for each parameter which maps a them directly to a property, which is in turn used by doctrine alter the queries dynamically. The issue is that I don't want {parameter} to be LInk-ed at all as it does not directly represent a property.
Is there a way to declare a parameter as a non identifier? Or as a non Link()? If you don't define a uriVariables entry for it then it assumes that it is the id for the mapped entity.
I had a similar issue and i resolved it using a fake public property in the entity itself (api-platform 2.7 with the flag to 3), and mapping the {parameter} to that property
'id' => 'fake_public_property'
#DynamoDBVersionAttribute
private long version;
We are not using annotations in our project. So for every model, we have a schema definition. I am not sure how to specify a version attribute field through schema definition.
StaticTableSchema.builder(User.class)
.newItemSupplier(User::new)
.addAttribute(String.class, a -> a.name("userName")
.getter(User::getUserName)
.setter(User::setUserName)
.tags(secondaryPartitionKey("userName-index"))) // GSI
.addAttribute(Integer.class, a -> a.name("id")
.getter(User::getId)
.setter(User::setId)
.tags(primaryPartitionKey())) // Primary Key
/*.addAttribute(Long.class, a -> a.name("version")
.getter(User::getVersion)
.setter(User::setVersion)
.tags(VersionRecordAttributeTags.attributeTagFor(null))
)*/
.build();
Based on the AWS docs for optimistic locking (e.g., C# and Java) this a feature of the mapping SDK, not a feature of DynamoDB or the table-attribute itself. If you look at the CreateTable API, there is no way to add an "automatic" versioning column. Looking at other DDB table APIs, there's no way to add it after the fact (like with TTL).
In order to accomplish this, you'll have to encode the use of Condition Expressions to effect a conditional update, setting an expectation for the pre-update value of the version attribute.
This answer has more information with a code example.
Use this tag "VersionedRecordExtension.AttributeTags.versionAttribute())"
See an example below:
.addAttribute(Long.class, a -> a.name("version")
.getter(Foo::getVersion)
.setter(Foo::setVersion)
.tags(VersionedRecordExtension.AttributeTags.versionAttribute()))
When using the MakerBundle in Symfony (4) to create new entity (make:entity EntityName), an id is generated by default with annotation (if annotations enabled) #GeneratedValue.
#GeneratedValue means #GeneratedValue(strategy="AUTO").
According to the Doctrine documentation, the AUTO strategy is supposed to use SERIAL type for the id in PostgreSQL. But, I do not know why in my case, the AUTO strategy use SEQUENCE for the id.
Then, I can force it to use SERIAL by changing by hand into #GeneratedValue(strategy="IDENTITY") which means using SERIAL type in PostgreSQL.
Is there any way to change the default #GeneratedValue annotation created by the MakerBundle for the new entities to be created with the #GeneratedValue(strategy="IDENTITY") annotation ?
What you could possibly do is decorate \Symfony\Bundle\MakerBundle\Doctrine\EntityClassGenerator which is registered as a service named maker.entity_class_generator in vendor/symfony/maker-bundle/src/Resources/config/services.xml and override its generateEntityClass method to make a different call on the Generator's generateClass method, specifically the file path could be changed there.
Seems like the file path there could be relative or absolute, so with some trial and error you could get it to output the annotation you want. The template that the maker bundle uses now is at vendor/symfony/maker-bundle/src/Resources/skeleton/doctrine/Entity.tpl.php, and it's pretty straightforward to modify.
#WebInitParam is an annotation that goes at class level.
It defines initialization parameters for the servlet.
I would like to know, what is the difference between doing this and using static variables, and why do it the #WebInitParam way rather than using statics?
What does defining k/v pairs as #WebInitParams allow you to do that you couldn't do if you declared static variables instead?
I have looked and all I can find is a million people saying how to define #WebInitParams. Well yes that's the easy bit. It's what I can do with that that is really what is of interest.
Thanks very much.
From a "raison d'etre" perspective, the annotation exists as a better design and architecture alternative to just peppering a class with static fields. #WebInitParam is a self-documenting approach to the initialization parameters a servlet or filter class needs, available via web.xml as well. It serves this purpose for the end developers as well as the JavaEE platform as a whole.
Think about it this way: in a vanilla project, you have the option of hardcoding a bunch of parameters in the class as static fields, or defining the same parameters in a property file. Which would you pick? Under what circumstances?
From a purely functional angle, apart from the function of using the annotation to override defaults set in web.xml, one other major reason is that you will sometimes need to get a hold of those initialization parameters from another component in your application. Using the annotation essentially increases the visibility of the parameter. In JSF for example, the API allows you to retrieve FacesServlet initialization parameters with:
//get all the parameters
FacesContext.getCurrentInstance().getExternalContext().getInitParameterMap()
//get a specific parameter
FacesContext.getCurrentInstance().getExternalContext().getInitParameter("aParameter");
In JSF-2.3 , it gets even more convenient with the following CDI-enabled injection:
#InitParameterMap Map<String,String> servletParameterMap;
Bear in mind that because it's CDI, it means this facility is available throughout the JavaEE platform, not just in web applications/JSF.
It's going to be a hassle to retrieve init parameters if the only mechanism available is a static field in the servlet class - you'll need to obtain an instance of the filter or servlet to get the static fields in it.
Separately, one could make the argument that maybe one should favour context-params over servlet-params because then, you get even more flexibility that isn't tied to any given servlet. That's a separate matter entirely :)
Can you set Swashbuckle documentation for an Operation at runtime?
Example: document list of values that are allowed, which is based on an internal dictionary but could also be based on configuration.
What does not solve the problem:
Use XML documentation: sets documentation from the XML comments in code. This is static instead of dynamic.
Set global description using the AddSwaggerGen method. This is dynamic, but at the wrong level.
Using an ISchemaFilter you can do some crazy documentation.
Here is an example:
https://github.com/heldersepu/csharp-proj/blob/master/WebApi_MyGet/WebApi_MyGet/App_Start/SwaggerConfig.cs#L277