I am trying to use DataNucleus's JDO in my own Java project (not GAE), and i need to store quite long pieces of text in my DB.
I am using Eclipse to do all the dirty work, like enhancing and creating the schema, but unfortunately, all String ivars are mapped to VARCHAR columns. But how do i get Datanucleus to create a LONGTEXT column for me?
I also tried the #Colunn annotation, but i still got the VARCHAR.
#Persistent
#Column(name="COMPONENT", jdbcType="LONGVARCHAR", length=1000000)
private String component;
I also tried specifying LONGTEXT as jdbcType, but the Schematool informed me, that that datatype could not be used.
Thank you in advance,
Happy New Year,
Best regards,
Timofey.
LONGTEXT is not a JDBC type. They are all clearly listed in http://docs.oracle.com/javase/6/docs/api/java/sql/Types.html
The DataNucleus log tells you what JDBC types are available for that JDBC driver (since it provides that information to the utilising software). It chooses to map JDBC type LONGVARCHAR onto "LONG VARCHAR" IIRC (easily visible by using SchemaTool "dbinfo"). You could obviously generate the schema into a text file and update it yourself before applying it.
#Persistent
#Column(name="COMPONENT", jdbcType="CLOB")
private String component;
The data type CLOB maps to medium text. But once the database is created you can change it to LONGTEXT
Related
My JPA entity has a UUID attribute, which is stored as char(36) in mysql. When I query data i'm receving 66323735-3039-6262-2d31-3764392d3466 instead of f27509bb-17d9-4f37-b336-8603f2d34394. When I enabled hibernate logs, I could see
org.hibernate.type.descriptor.sql.BasicExtractor - extracted value ([col_1_0_] : [BINARY]) - [66323735-3039-6262-2d31-3764392d3466]
extracted value is [BINARY] instead of [VARCHAR] like other attributes.
Any clue as to why this is happening?
Also,
I've tried to run hibernate generated query on mysql and that returns correct results.
Other column values including UUIDs are being returned correctly.
I'm using an interface based entity projection to retrieve limited data and not the whole entity.
edit: I just added trim(colName) and now it's returning correct UUID value. But still not sure of the issue at hand.
Do this for hibernate 6. It will generate character type (for mysql char(36)).
#org.hibernate.annotations.JdbcTypeCode(SqlTypes.CHAR)
protected UUID id;
We have a scenario to load Image column from SQL Server which is our source and load into Snowflake, but its failing due to "String Long Issue" as Snowflake has Varchar Limitations.
Till now, we have tried Varchar and Variant datatypes as well to load this Image datatype but due to the huge size its failing for Variant as well (Snowflake is trying to read it as JSON , that's why we have tried variant as well).
Is there is any way to overcome this limitation of Varchar data type length in snowflake.
You'll need to handle that as unstructured data, which is a recently-released public preview.
https://www.snowflake.com/blog/snowflake-launches-unstructured-data-support-in-public-preview/
This shows how to get started:
https://docs.snowflake.com/en/user-guide/unstructured-intro.html
If you try something and it's not working, you can update your question with the code you're trying and others can try to help out.
Using DataType.LONG_STRING attribute value Persisted as SQL type LONGVARCHAR which handles longer strings.
However, i want to map the field to SQL type TEXT .
#DatabaseField(dataType = DataType.LONG_STRING)
String comment;
Since there is a difference between LONGVARCHAR and TEXT SQL Type, DataType.LONG_STRING value does not solve the problem
So by default the LONG_STRING type is supposed to generate TEXT as the schema -- Postgres and MySQL do for example. What database type are you using? Derby generates LONG VARCHAR, Hsqldb LONGVARCHAR, and Oracle LONG. I think this was for compatibility reasons.
There a couple of ways that you can override the schema that ORMLite produces. The easiest is to define the column yourself with the columnDefinition part of the #DatabaseField:
#DatabaseField(columnDefinition = "TEXT")
String comment;
If you are making more complex changes to the database compability code, you can also override the DatabaseType you are using. In this case you can override the appendLongStringType(...) method to produce a different schema. I'd override DerbyDatabaseType or whatever database you are using and then add something like:
#Override
protected void appendLongStringType(StringBuilder sb, FieldType fieldType,
int fieldWidth) {
sb.append("TEXT");
}
I want Entity Framework to store all my dates as DateTime2 data type.
I have ProviderManifestToken="2008" in my SSDL and still all the generated dates are DateTime instead of DateTime2. What am I missing?
You are not missing anything. Entity framework never uses DataTime2 unless you manually modify its database generation process (only in model first approach). You need to update SSDLToSQL10.tt file to use DateTime2 instead of DateTime. Check the end of this answer for more details about modifying the template and configuring VS to use the new template.
Borland StarTeam seems to store its data as UTF-8 encoded data in VarChar fields. I have an ASP.NET MVC site that returns some custom HTML reports using the StarTeam database, and I would like to find a better solution for getting the correct data, for a rewrite with MVC2.
I tried a few things with Encoding GetBytes and GetString, but I couldn't get it to work (we use mostly Delphi at work); then I figured out a T-SQL function to return a NVarChar from UTF-8 stored in a VarChar, and created new SQL views which return the data as NVarChar, but it's slow.
The actual problem appears like this: “description†instead of “description”, in both SSMS and in a webpage when using Linq2SQL
Is there a way to get the proper data out of these fields using Entity Framework or Linq2SQL?
Well, once you get the data out, you could always try this:
Encoding.UTF8.GetString(Encoding.Default.GetBytes(item.Description))
assuming the field is encoded in the system ANSI page. You might have to create the right encoding with Encoding.GetEncoding() if for some reason it isn't (looked up from DB type, for example).