Hi there i'm using jhipster 4.9.0 and while i'm generating entity with jhipster sub entity generator it creates all the files but it does not add jhi key word in the files.
Like
<-alert>
#Component({
selector: '-abcd-zyx',
templateUrl: './abcd-zyx.component.html'
})
The jhi prefix is only used in the database(liquibase) to avoid using key words.
Related
I'm using NestJS (not Next) NodeJS framework
When I'm creating new objects I used to use new OjbectClass({...fieldsValues});
It's great especially when you use transform pipes from class-transformer;
Besides this approach is used for entity creating:
https://docs.nestjs.com/techniques/database#separating-entity-definition
But as far I see in different guides of TypeOrm usage
here: https://typeorm.io/#/ ,
and here: https://orkhan.gitbook.io/typeorm/docs/entities .
They show first to create an empty object, then only set fields with values:
const object = new EntityObject();
object.field = 'value';
Why? Does it make sense?
Does NodeJS create a redundant hidden class of properties passed via object into Entity Class constructor? If yes - then we can pass coma-separated arguments
I believe it's just cause that's how the docs are. Looking at the code for BaseEntity it does not look like having a constructor to assign the fields would be a problem
For an API server, I have a set of models, e.g.
Recording <-> Artist
with ManyToMany relation in TypeORM. The relation needs to be defined in both sides models.
In certain routes I am displaying only Recording and in certain routes also Recordings with Artists, using leftJoinAndSelect. E.g. /api/artists and /api/artists_with_recording.
However, the generated documentation always shows Recordings in Artists.
Is there some easy way to modify the swagger output?
I could make different model objects with swagger markup but with more objects in more contexts that could become pretty messy.
After more searching, I found a solution. I can use the OmitType function from NestJS to create simple ad hoc classes for the documentation.
https://docs.nestjs.com/openapi/mapped-types#omit
So for the route /api/artists I do
#Entity()
class Artist {
...
}
class ArtistWithoutRecording extends OmitType(Artist, ['recording'] as const)
In the controller documentation, I include the ArtistWithoutRecording type.
#Get('artists')
#ApiOperation({
summary: 'Get all artists',
description: 'Some description'
})
#ApiOkResponse({ type: ArtistWithoutRecording })
async getArtists() {
return this.artistDao.findMany()
}
I tried creating a JHipster app with one of the options: --skip-client.
Also I disabled Liquibase afterwards.
Then I created a test entry, similar to:
entity Test {
id String,
hireDate ZonedDateTime
}
I put this into a test.jh file, executed on a terminal:
jhipster import-jdl test.jh
When I looked into the Java source of the app, I discovered a Test.java class, id was automatically recognized as a primary key I believe:
#Id
#GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequenceGenerator")
#SequenceGenerator(name = "sequenceGenerator")
private Long id;
But hireDate was annotated with:
#Column(name = "hire_date")
private ZonedDateTime hireDate;
Why is that?
I created a view "Test" for this entity in my database, also the columns are "Id" and "HireDate".
But with the automaticaly added #Column annotation, the column name for example "hire_date" doesn't exist in my view.
Can I solve this somehow? I this something related to JHipster generator or to do with Spring Boot?
And there is another issue:
#Size(max = 100)
#Column(name = "jhi_type", length = 100)
private String type;
To name a Java field "type" seems ok, but JHipster makes "jhi_type" for #Column
Cheers
These are the JHipster naming conventions: snake-case for columns and camel-case for java entity fields. If you had used Liquibase, this would have worked fine.
You can't configure this behavior in the generator.
Disabling liquibase does not change the fact that you created a view in your database that does not respect JHipster naming conventions. JHipster generates code that expects columns to be named this way. Either you respect these conventions or you modify the generated code manually.
Alternatively, you could try jhispter-db-helper module but it seems this project has been abandoned.
No need to define the id field in the jdl, you get it for free by default.
The example only shows loading of 1 locale which is bg.
How are we able to load all the locale so that we can change the locale dynamically. Thanks in advance!
http://plnkr.co/edit/Ucx0SlcmBfN9TRjrS5Ad?p=preview Plunker
[Short answer]
You can't change the locale of the Angular application dynamically, without recreating the module/component.
[Long version]
The locale of the Angular component is determined by the LOCALE_ID, which is injected through the Angular DI system. Considering the fact the Angular uses constructor based dependency injection, the component needs to be recreated in order to receive new LOCALE_ID value.
That being said, the only feasible solution to have components/modules with different locales is to wrap them with high order component that will provide different LOCALE_ID:
#Component({
selector: 'bg',
providers: [{
provide: LOCALE_ID,
useValue: 'bg-BG'
}, {
provide: IntlService,
useFactory: (localeId: string) => new CldrIntlService(localeId),
deps: [LOCALE_ID]
}],
template: `
<ng-content></ng-content>
`
})
export class BGComponent {
}
Here is runnable demo:
http://plnkr.co/edit/gmAWVLD1Yzn353QA1eDj?p=preview
Please note, that the plunker demonstrates how to place components with different locale on one page. As I mentioned, fully dynamic change of the locale is not possible (excluding the all possible hacks, of course). If there is a good solution out there using LOCALE_ID, I'd be more than happy to see it.
I need to perform a search on several entities with the same string then order the results.
I've heard/read a little about FOSElasticaBundle, would this bundle be able to do it? It seems (to me) to have almost to much features for this purpose and I'm not sure it could run on a shared server (hostgator).
The other solution I can think of at the moment is doing the search "manually" (by using join and union) but I'm wondering where should I put such a function: in an existing controller, a new one, a new bundle or somewhere else?
I'm worried as well that this manual solution could come to a cost, especially on some non-indexable fields.
You would do custom entity repositories. Check out the docs. Basically this extends the default FindAll, FindOneBy, etc.
You would have a function like so:
class MyEntityRepository extends Doctrine\ORM\EntityRepository {
public function findByCustomRule(){
//this is mapped to your entity (automatically adds the select)
$queryBuilder = $this->createQueryBuilder('someAlias');
$queryBuilder->orderBy('...');
//this is mapped to any entity
$queryBuilder = $this->getEntityManager()->createQueryBuilder();
$queryBuilder->select('...');
//result
$result = $queryBuilder->getQuery()->getResult();
}
}
This class is defined in the doctrine mapping and lives inside the Entity folder.. Check the docs out and you should get a basic idea.