Can I create Groovy script for creating Pojo from Database object type ?
Answered
Now I can create Pojo only from table. This row:
it instanceof DasTable && it.getKind() == ObjectKind.TABLE
check that object is Table only. How can I check and iterate fields DB object types ?
Please sign in to leave a comment.
See this blog post: https://blog.jetbrains.com/datagrip/2018/02/13/generate-pojos/ and mentioned at the end existing examples and documentation.
See also Extending DataGrip functionality and this forum threads for some more information about API
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206631935-Scripted-Extensions
https://intellij-support.jetbrains.com/hc/en-us/community/posts/205993979
Oh thx. But can you explain how to add "src_database-openapi.zip" to enable autocopletion ?
You can add it as any other Java library.
I try almost all ways of adding library and dependancies in project, but all without result. Can you show how to add .zip or extracted library step-by-step ?
You need to un-pack the zip to a jar archive.
I try this before. Library and dependancy added in Project Structure (without problems) but not added to External Libraries of project. Maybe Im doing something wrong =(.
Oh, I see now! I'm sorry, these are actual sources only without classes and are not packaged to a jar. So if you want a completion you should un-archive the zip and add them to your java module as a separate content root then mark the "src_database-openapi" folder as a source root.
You only do not need to actually compile these classes, so it would make sense to exclude them from compiler in Settings(Preferences) | Build, Execution, Deployment | Compiler | Excludes.
Yeah thx ! It`s works ! I leave here my code for other people who will want iterate arguments in UserDefinedType:
FILES.chooseDirectoryAndSave("Choose directory", "Choose where to store generated files") { dir ->SELECTION.filter { it instanceof DasUserDefinedType }.each { generate(it, dir) }
}
def calcFields(DasObject table) {table.getDasChildren(ObjectKind.OBJECT_ATTRIBUTE).reduce([]) { fields, col ->
def spec = Case.LOWER.apply(col.dataType.specification)
def typeStr = typeMapping.find { p, t -> p.matcher(spec).find() }.value
fields += [[
name : javaName(col.name, false),
type : typeStr,
annos: col.comment ? """
/**
* $col.comment
*/""" : ""]]
}
}
Hi - I hope you don't mind my hijacking this thread but I too have been working with the scripted extension features in an effort to build hibernate mapping files for a database of some 700+ tables.
My first issue was how to generate a single pojo class for tables with a single column primary key and a pair of classes (Entity and EntityPK) for tables with complex multi-column primary keys. After a number of false starts (I'm a groovy newbie) I managed to achieve this by first evaluating the number of columns in the primary key generally as follows.
FILES.chooseDirectoryAndSave("Choose directory", "Choose where to store generated files") { dir ->
SELECTION.filter { it instanceof DasTable && it.getKind() == ObjectKind.TABLE }.each {
generateClasses(it, dir)
}
}
def counter(table) {
def fields = calcFields(table)
count = 0
fields.each() {
if (it.primary) {
count++
}
}
return count
}
def generateClasses(it, dir) {
if (counter(it) > 1) {
generate(it, dir)
generatePK(it, dir)
} else {
generateSingle(it, dir)
}
}
I have the output as needed with the MAJOR exception of mapping the foreign key relationships. I see that there is a method
but I'm struggling to understand how I can extract the table:column relationship data from the returned JBIterable<? extends DasForeignKey> data.
Any pointers you can give would be most helpful.
I think you can try to use default DasObject method (getDasChildren(ObjectKind.FOREIGN_KEY)) instead of DasUtil method
Also this link may be helpful:
https://gist.github.com/virtualadrian/519fe0dc6658fe60500067bee3134c97
Hi Imperius
I'm part way to solving the problem using the DasUtil.getForeignKeys(table) method. The difficulty is the lack of documentation I think both DasUtil.getForeignKeys(table) and (getDasChildren(ObjectKind.FOREIGN_KEY)) will return iterable DasForeignKey objects.
Using reflection, I discovered the the objects returned as ForeignKeys are actually DbForeignKeyImpl objects which are not part of the opensource code. DbForeignKeyImpl declares the following methods:
public com.intellij.database.psi.DbTable com.intellij.database.psi.DbForeignKeyImpl.getTable(),
private static void com.intellij.database.psi.DbForeignKeyImpl.$$$reportNull$$$0(int)
public int com.intellij.database.psi.DbForeignKeyImpl.getWeight(),
public boolean com.intellij.database.psi.DbForeignKeyImpl.isUnique(),
public java.lang.String com.intellij.database.psi.DbForeignKeyImpl.getTableName(),
public com.intellij.database.model.MultiRef com.intellij.database.psi.DbForeignKeyImpl.getColumnsRef(),
public com.intellij.database.model.DasTable com.intellij.database.psi.DbForeignKeyImpl.getRefTable(),
public com.intellij.database.psi.DbTable com.intellij.database.psi.DbForeignKeyImpl.getRefTable(),
public java.lang.String com.intellij.database.psi.DbForeignKeyImpl.getRefTableName(),
public com.intellij.database.model.MultiRef com.intellij.database.psi.DbForeignKeyImpl.getRefColumns(),
public com.intellij.database.model.DasForeignKey$Deferrability com.intellij.database.psi.DbForeignKeyImpl.getDeferrability(),
public com.intellij.database.model.DasForeignKey$RuleAction com.intellij.database.psi.DbForeignKeyImpl.getDeleteRule(),
public com.intellij.database.model.DasForeignKey$RuleAction com.intellij.database.psi.DbForeignKeyImpl.getUpdateRule(),
public boolean com.intellij.database.psi.DbForeignKeyImpl.isPrimary(),
protected com.intellij.database.model.MultiRef com.intellij.database.psi.DbForeignKeyImpl.getDelegateColumnsRef(),
public java.lang.String com.intellij.database.psi.DbForeignKeyImpl.getRefTableCatalog(),
public java.lang.String com.intellij.database.psi.DbForeignKeyImpl.getRefTableSchema()
I think it's time for Jetbrains to come clean and either support this functionality properly or drop the feature altogether - I've wasted many hours on this already and I don't appreciate having to use reflection to discover what should be fully documented.
On the plus side, I have now got some code that will produce the @ManyToOne relationships like: