Alternatives to com.google.appengine.api.datastore.Text? - java

In a Google App Engine JPA Entity a java.lang.String is limited to 500 character, while a com.google.appengine.api.datastore.Text has an unlimited size (with the caveat that entityManager.persist doesn't work with entities bigger than 1 Mb - I believe, but can't find the reference about it).
However, if I use the Google specific Text type, I would tightly couple my application with Google App Engine. I was wondering if there is a more lightweight way to achieve the same result, such as through some standard annotation.
Maybe, annotating a String with a JSR-303 annotation. If the size is above 500, it would know to use the non-indexed Text type. Example: #Size(max = 3000)
Obvsiously I'm just dreaming, but maybe there is some standard way to avoid App Engine specific data types. Anybody knows?
UPDATE: found issue 10, Support #Lob JPA annotation in datanucleus-appengine
DataNucleus plugin for Google App Engine.

I'm guessing you might have thought of this already; but I'm posting this anyway since it adds a point not covered in your question. My solution here was to make it private, and then for my object definition I don't ever return a Text object. I admit this doesn't accomplish your goal of avoiding the App Engine specific data type; but it at least makes it so that you don't have to rewrite code outside of the one class which relies on the Text object should you decide to port your application off of app engine.
So, for example, assuming text is a blogPost variable...
public class BlogPost {
private Text post;
// ...
public String getPost() {
return post.getValue();
}
public void setPost(String val) {
this.post = new Text(val);
}
}
If that code feels a little sloppy it might be slightly (I don't know how the Text#getValue method works internally) more efficient to do this...
public class BlogPost {
private Text post;
private String postValue;
// ...
public String getPost() {
return postValue;
}
public void setPost(String val) {
this.post = new Text(val);
this.postValue = val;
}
}

Related

How to store UUID fields in Java classes?

I work on an android project and have performance problems with UUID fields. Here is the project sample code (not written by me):
public class OrderVo {
#Expose
#SerializedName("UId")
private UUID mGuId;
public String getGuId() {
return UUIDHelper.toString(mGuId);
}
public void setGuId(String guId) {
mGuId = UUIDHelper.fromString(guId);
}
...
This object is used in RecyclerView and its methods are called in bindData of the adapter. This causes a performance issue cause on every scroll getGuId() is called and String objects are created from UUID and GC is actively working to clean that objects (and that causes lag when fast scrolling). Is there any benefits of keeping mGuId field as UUID and not a simple String?
If the callers do not convert the UUID-string back to a string you can indeed store the values as String.
One drawback with this solution is the missing type checking. The string must not contain a UUID but can contain anything else.

Strings in OSGI Enroute DTOs are 'compressed'

My current task is to build an application using OSGI Enroute (http://enroute.osgi.org/) and Angular (though we elected to use Angular2/4 instead of the bundled AngularJS).
So far so good. I have a REST Java application which is responding to various requests from the Angular front-end but I'm currently running into an issue. In order to make development easier I am serving the Angular code on port 4200 and the back-end is listening on port 8080. CORS is working so I am able to send and receive requests while building the code. This may or may not be related to the issue.
The issue is when responding with a DTO with String content in excess of 21 characters the value is getting 'compressed.' I noticed this when attempting to use the value I received (a UUID) as a key for a subsequent GET request. Checking the DTO class I have confirmed that the toString() method does indeed call a private compress method where it will take any string longer than 21 characters and return something akin to this nine...last nine which tends to make it difficult to re-obtain a UUID from ... {"uuid":"95b90155-...ee5c02200", "name":"My Object"}...
So ... given something like this:
import org.osgi.dto.DTO;
public final class MyDTO extends DTO
{
public String uuid;
public String name;
}
and a REST application like this:
#RequireBootstrapWebResource(resource="css/bootstrap.css")
#RequireWebserverExtender
#RequireConfigurerExtender
#Component(name="web", propery={"debug=true"})
public final class MyApplication implements REST
{
private boolean debug = false;
public MyDTO getMe(RESTRequest request)
{
MyDTO dto = new MyDTO();
dto.name = "My Object";
dto.uuid = UUID.randomUUID().toString();
return dto;
}
#SuppressWarnings("unused")
#Activate
void activate(ComponentContext component, BundleContext bundle,
Map<String, Object> config)
{
if ("true".equals(config.get("debug"))
{
debug = true;
}
}
}
what am I missing in order to avoid this value 'compression' in my JSON responses?
Things I have tried
(The one that works) overriding the toString() method provided by DTO. This works but doesn't seem like it is the best solution. I would then have to override the toString() for anything that might have a string value in excess of 21 characters. The documentation indicates that the intent is for debugging, which likely means I'm not returning the proper type?
Setting the request's _response()'s content type to application/json: the result I see in the Chrome Web console is still a compressed string
I wrote the DTO.toString methods. It is clearly documented that the format of the output is not specified and that it is for use as a debugging tool and not for serialization. This is is why the impl "compresses" strings.
If you need to serialize a DTO, you need to use code for that purpose. See https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.base.api/src/osgi/enroute/dto/api/DTOs.java for an API that can convert DTOs to a format like JSON.

How to get resource link for pagination in katharsis

I'm trying to do pagination. What I have works, but I have some doubts about the way I get a Resource URL.
In my Resource Repository, I inject a ResourceRegistry in a Lazy way (I know it's a circular dependency) to get a URL for my Resource that I then use to generate my links.
String resourceUrl = resourceRegistry.getResourceUrl(Book.class);
It works fine, but the circular dependency bothers me. Is there some static class to get a resource URL. Or perhaps there's a completely different way of approaching this?
Maybe this is not a satisfying answer, but katharsis does generate links in it's serializers. You could probably extend one of the katharsis' serializers and make it aware of optional meta information, containing the total number of items available, which the client would need to know anyway. From this data, you could create the top level links for prev and next pages. In the katharsis serializers the resourceRegistry will be available anyway, along with QueryParams, containing the original pagination parameters.
This is all very hypothetical though.
The suggested solution by katharsis devs would be:
#JsonApiFindAll
public JsonApiResponse findAll() {
return new JsonApiResponse()
.setEntity(Collections.singletonList(new Task(1L, "John")))
.setLinksInformation(new LinksInformation() {
public String self = "...";
public String first = "...";
public String prev = "...";
public String next = "...";
public String last = "...";
});
}
Taken from here:
https://github.com/katharsis-project/katharsis-core/issues/307
https://github.com/katharsis-project/katharsis-core/issues/328
Still, hand-crafting the links seems required.

how to keep server side Java and client side JS DTO properties consistent

Hi I’m looking for a solution/plugin in Eclipse to keep server-side Java DTO properties and their client-side JSON counterparts consistent throughout the evolution of the codebase. For example, for a webapp with a Java backend, with APIs exposed through a REST interface (using Jackson), the webapp could have something like this on the server:
the DTO:
public class Person {
private String firstName;
private String lastName;
public Person(String string, String string2) {
firstName = string; lastName = string2;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
The REST Service:
#Path("/data")
public class PersonService {
#GET
#Path("persons")
#Produces(MediaType.APPLICATION_JSON)
public List<Person> getAssets() {
List<Person> persons = new ArrayList<Person>();
persons.add(new Person("Jimmy", "Hendrix"));
persons.add(new Person("Roger", "Waters"));
return persons;
}
}
On the Client side, in Javascript/JQuery, we can have code like this:
$.ajax('/data/persons/', function(data){
for(var i = 0; i < data.length; i++){
var firstName = data[i].firstName;
var lastName = data[i].lastName;
//do some stuff to populate the view with the person data
}
});
This is all straightforward to set up. However, as the codebase evolves and changes (as it always does), suppose there is a need to change the names of the DTO fields from “firstName” and “lastName”, to “foreName”, and “surName”.
In Eclipse, refactoring all of the Java code is simple using the Refactor menu item, which will find ALL references of the method/field in the Java code, and replace them. Note that Eclipse’s “Refactor…” is different than a Find/Replace action. Find/Replace does a basic text replace on all files specified. Refactor on the other hand, takes into account that Java is a strongly typed programming language, and searches for all method invocations with that signature.
It would be great if there was some plugin or Eclipse feature that would be smart enough to change the reference to “firstName” and “lastName” in the Javascript code as well. That would save developers the time of having to do a Refactor for just the Java code, and then a selective Find/Replace in the Javascript code, and reduce potential runtime errors. Does anyone know if such a tool/plugin exists?
Yeah, me too. This seems like a pattern I encounter at every job.
Best I've done in the past is generate Javascript stubs from the java DTOs and used JsDoc to indicate where those javascript DTOs are used.
If I was doing that same solution today, I'd probably see what Swagger codegen would give me out of the box.
Intellij at least will highlight missing fields in the javascript, which is helpful.
It would be great if there was a plugin, but this was better than nothing.
With typescript you'd even get compile safety with the stubs.
For the JavaScript snippet you presented in the question, such a tool is probably impossible to write.
However, there are things you can do to improve the situation.
On one side, you can write a generator for JavaScript representations of your DTOs. IDE-friendly strategy would be to generate objects that have properties with default values. Like
var Person = { firstName: "", lastName: "", roles:[] };
Even if you do not actively integrate such a file into the actual web UI, it helps to reduce typo errors by checking the warnings IDE will throw at you.
On another side, you could/should use a real JavaScript model layer. Then you can validate all DTO JavaScript representations during automated testing and/or with a special button in e.g. maintenance part of the UI that QA always verifies before release. If you upgrade your web UI together with the server, it definitely helps to catch missed refactoring leftovers.
Validation endpoint would receive a JSON object like this:
{ "Person": {...}, "Address": {...}, "Item": {...}, ... }
and run it against package(s) with DTOs using a little bit of Java reflection. Of course, you could also use Nashorn engine in Java to do the validation directly on the server, e.g. during server start-up.
It is not a silver bullet, it just greatly helps to reduce errors. In the end, the less obscure logic you have in the UI, the easier it is to do the refactorings. Create or use generic, universal components, wire them up to DTOs in a very thin translation layer that uses label look-up tables, which can be validated as well. Also helps with i18n.
Generation and validation can be used separately or together in one project.
BTW, one of the reasons to choose GWT for UI layer some years ago was to achieve exactly what you want. I haven't been following it for a while, but it would be hard to imagine its drawbacks will outweigh this benefit.
There is no such plugin. Welcome to the world of languages that are not statically typed.

Know the type of a word on Lucene

I'm working on Lucene, as a Newbie and I'm searching a way to find in a tokenstream.
If it's a verb, a name, or other.
I see the method type() for the token's class but I'm using the class CharTermAttribute.
I have already tried to find a way on the API doc, but i don't found anything for this.
#EJP is correct, that Lucene doesn't know anything about parts of speech on it's own.
However, you could implement a custom filter that handles this well. Lucene's TokenStream API example implementation actually does exactly that. I'll include a few pertinent bits here, but also look over the complete example (starts about halfway down the page).
Two things, in particular, seem of primary interest. First, creating a custom PartOfSpeechAttribute interface extending Attribute. These Attributes are used to attach some attendant data to tokens during analysis. A simplified version of that provided in the example (again, visit the link above to see their more robust implementation):
public class PartOfSpeechAttribute implements Attribute {
public static enum PartOfSpeech {
Noun, Verb, Adjective, Adverb, Pronoun, Preposition, Conjunction, Article, Unknown
}
private PartOfSpeech pos = PartOfSpeech.Unknown;
public void setPartOfSpeech(PartOfSpeech pos) {
this.pos = pos;
}
}
Then you will need to implement your custom filter which adds these attrributes to each Token.
public static class PartOfSpeechTaggingFilter extends TokenFilter {
PartOfSpeechAttribute posAtt = addAttribute(PartOfSpeechAttribute.class);
protected PartOfSpeechTaggingFilter(TokenStream input) {
super(input);
}
public boolean incrementToken() throws IOException {
if (!input.incrementToken()) {return false;}
posAtt.setPartOfSpeech(determinePOS(termAtt.buffer(), 0, termAtt.length()));
return true;
}
// determine the part of speech for the given term
protected PartOfSpeech determinePOS(char[] term, int offset, int length) {
// ???
}
}
Then you would be able to extract the PartOfSpeechAttributes from the TokenStream much like you would any other attribute.
Of course, that doesn't answer how to determine the Part of Speech. The implementation of determinePOS is somewhat beyond the scope I can expect to cover here though. OpenNLP might be a good library for making that determination, among others.
There is also some as yet in development work on an OpenNLP analysis module that would definitely be work a look, though it doesn't look like parts of speech are handled by it yet, nor that it has got much love in in about a year.

Categories

Resources