I figured out that if entity class has #jsonAutoDetect annotation, the Q class not generated,
Here is the example :
https://github.com/prilia/SpringJpa-Quarydsl-Test/tree/master/JpaSpringQuarydsl
If remove JsonAutoDetect Q classes genereted fine,
Please, how can I use with entity class as json ?
In cases like these always disable the execution of the ATP plugin and see if your build has other issues.
e.g. https://github.com/prilia/SpringJpa-Quarydsl-Test/blob/master/JpaSpringQuarydsl/pom.xml#L432
import is not a valid scope.
Related
I am trying to figure out what class Meta: really do in Django.
I come across with the code below in DRF, but not sure why under class Meta: there is model = User and fields = [...]. Does it help to create a database?
from django.contrib.auth.models import User, Group
from rest_framework import serializers
class UserSerializer(
serializers.HyperlinkedModelSerializer):
class Meta:
model = User
fields = ['url', 'username', 'email', 'groups']
And also what is the different with the class Meta: used in Django as below.
from django.db import models
class Ox(models.Model):
horn_length = models.IntegerField()
class Meta:
ordering = ["horn_length"]
verbose_name_plural = "oxen"
I have tried to get further understanding from both Django and DRF documentation however I did not see the explanation for model = ... and fields = [...] used in DRF class Meta.
Hope someone could help to explain the functioning principle behind. Thanks!
The Meta class is merely a convenient place to group metadata (meaning data about the data) that DRF needs to adjust its configuration, but keep this separate from the attributes of the class itself. This separation allows the Django Rest Framework (and the wider Django Framework ecosystem) to avoid clashes between configuration and the actual class definitions.
The use of an inner Meta class is a common pattern throughout Django, because this allows you to both keep this configuration separate from the fields of the class and keep it connected to the class in a way that's easy to read and easy for the framework to find. A DRF selialiser class should normally have one or more fields to help turn data into a serialized form, but the HyperlinkedModelSerializer base class can generate these fields for you if you tell it what model you wanted to serialise. The fields on the Meta class tell it you want to serialize specific fields from your User model.
By putting this configuration on the inner Meta class, they are kept in a separate namespace from the main class, but at the same time remain connected to the class they are meant to configure. Imagine a model that has a field named model and fields for example. If the HyperlinkedModelSerializer required that configuration is found in the subclass itself, you could never produce a serializer that could process something with model and fields fields!
If you wanted to know what the different options are you can use on the inner Meta class, you need to read the ModelSerialiser and HyperlinkedModelSerializer documentation in the API guide section.
For Django Models, you can refer to the Model Meta chapter of the Django documentation. As I stated above, it's the same concept but here the Meta class configures the database fields that the model supports and how the model relates to other database models you may have defined.
Last but not least, there is another answer here that confuses the term Meta with Python Metaclasses, which is a very different concept. While DRF and Django model classes lean heavily on metaclasses for their internal implementation, the class Meta: definition you use to configure the framework functionality, they are not metaclasses. They are plain classes that are only used because they make for a convenient namespace.
class Meta is used in DRF serializers to configure your serializer.
model defines the model to which your serializer is linked.
fields is a list of properties that you would like to serve in your API.
Use fields = ['__all__'] to serve all properties
Use exclude = ['your_excluded_prop_1', 'your_excluded_prop_2'] to exclude properties
The concept of Meta class comes from metaprogramming. The term metaprogramming refers to manipulating itself. Python supports a form of metaprogramming for classes called metaclasses. Meta class is mainly the inner class of your main class. Meta class is basically used to change the behavior of your main class attributes. It’s completely optional to add a Meta class to your Class. But in your Django project, you have already seen this metaclass concept available in different places like models.py, serializers.py, admin.py, etc.
Actually, this Meta class changes the common behavior of its main class like the model metaclass changing behavior using verbose_name, db_table, proxy, permissions, ordering etc, and a lot of other options. Meta class in serializer also does the exact same things it tells it the model to use and what fields to serialize by using fields, exclude, and model.
Good Luck :)
so I was playing a bit with Mapstruct, reading the reference Documentation for the Version 1.1.0.Final, and arrived at the point:
implicit type conversions
where is defined the following statement:
Between JAXBElement < T> and T
I tried that, but the error what I received was:
Can't map property "java.lang.String xmlElement" "javax.xml.bind.JAXBElement<java.lang.String> xmlElement".
Consider to declare/implement a mapping method:
javax.xml.bind.JAXBElement<java.lang.String> map(java.lang.String value)".
I know thisi is the same thread asCan't map property when using MapStruct but since then Mapstruct released a new version.
Am I doing something wrong or this feature really is missing?
Thank you.
Mapping from JAXBElement<T> to T works out of the box. For the reverse you need to make sure that the ObjectFactory(ies) are in the Mapper#uses, MapStruct uses those methods to create the types.
You can also have a look at this integration test.
In case this happens on Java 9 or higher and you use implementation of type JAXBElement from maven library (in my case'javax.xml.bind:jaxb-api') make sure it is on the classpath of the annotation processor - this resolved the issue for me.
If your JAXBElement was generated by a wsdl client generator (eg. xjc) you need to provide the corresponding ObjectFactory.class generated by the client generator:
#Mapper(uses = ObjectFactory.class)
public interface OrderMapper {
Order orderEntityToExternalOrder(OrderEntity orderEntity);
}
See:
MapStruct 1.0.0.Beta1 is out with JAXB support, custom factories, decorators and more
I am trying to serialize a object in GWT using SerializationFactory, but I am not able to get it working. Here is the sample code of my POC:
import com.google.gwt.user.client.rpc.SerializationException;
import com.google.gwt.user.client.rpc.SerializationStreamFactory;
import com.google.gwt.user.client.rpc.SerializationStreamReader;
import com.google.gwt.user.client.rpc.SerializationStreamWriter;
...........
Some code here....
.........
......
SerializationStreamFactory factory = (SerializationStreamFactory) GWT.create(MyClass.class);
SerializationStreamWriter writer = factory.createStreamWriter();
try {
writer.writeObject(new MyClass("anirudh"));
String value = writer.toString();
SerializationStreamReader reader = factory.createStreamReader(value);
MyClass myObj = (MyClass) reader.readObject();
System.out.println(myObj.getName());
} catch (SerializationException e) {
e.printStackTrace();
}
It gave me the following exception
Caused by: java.lang.RuntimeException: Deferred binding failed for 'com.anirudh..client.MyClass' (did you forget to inherit a required module?)
also in my code the class whose object I am trying to serialize implements IsSerializable
MyClass implements IsSerializable
I don't want to use GWT Auto-Bean framework because it does not fit my use case. Also I am not using GWT-RPC framework and right now I am quite adamant about using SerializationStreamFactory :D because I seriously want to know how this thing works.
Can anyone share a working example of SerializationStreamFactory or help me out pointing any mistake(s) I did.
Thanks in advance
SerializationStreamFactory factory = (SerializationStreamFactory) GWT.create(MyClass.class);
What are you expecting this line to do? GWT will attempt to find a replace-with or generate-with rule that matches this class (either when-type-assignable or when-type-is), or failing that will attempt to invoke a zero-arg constructor on MyClass, effectively new MyClass(). Is this what you are expecting?
The selected exception you've pasted suggests that MyClass may not be on the source path that GWT has been given to compile from, but the full error log will provide more information.
It looks as though you are trying to mimic the generated RPC code, where a *Async rpc interface would be implemented by code that extends from com.google.gwt.user.client.rpc.impl.RemoteServiceProxy (which implements SerializationStreamFactory). That base implementation is extended further to initialize several fields such as the com.google.gwt.user.client.rpc.impl.Serializer instance, actually responsible for serializing and deserializing object streams.
Serializers are created (by default) from the base class of com.google.gwt.user.client.rpc.impl.SerializerBase, through the rebind class com.google.gwt.user.rebind.rpc.TypeSerializerCreator. If you've build your own generator for MyClass, you should be kicking this off to get the work done as ProxyCreator already should be doing.
Remember when building your own serialization/deserialization mechanism that you need to decide which types can be marshalled within this system - if you open it to all types, then you will need to generate FieldSerializer types for all possible objects on the source path. This will greatly expand the size of your compiled code.
If your main goal is learning how this 'magic' works, dig into the generators and associated code that live in the com.google.gwt.user.rebind.rpc package. There are other libraries that leverage these ideas such as the gwt-atmosphere project (see https://github.com/Atmosphere/atmosphere to get started). Also review the generated code that GWT creates when it builds a 'tradition' RPC interface.
few days ago i read tutorial about GenericRepository and Unit Of Work patterns http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application. I use web forms and i have EntityFramework CTP4 package installed. (I can't using EF 5).
I want to code generic repository for my project but i was stuck at this line:
this.dbSet = context.Set<TEntity>();
I know that this line doesn't work because a use ObjectContext in my project and database first approach. How can i deal with it? Can I code generic repository without migration to code first (which is not an option in my case) ?
This is the equivalent for ObjectContext:
this.dbSet = context.CreateObjectSet<TEntity>();
Now this creates an ObjectSet<TEntity> rather than a DbSet<TEntity>, but for your pattern you can use it in the same way.
UPDATE
The ObjectSet class does not have a utility method like that matches the Find() method of the DbSet. In order to "Get by key" you would need to construct an EntityKey and use the ObjectContext.GetEntityByKey(), unfortunately that's not a really simple thing to do.
There really isn't a simple way to tackle this, that I've found. In my case what I've done is to base all of my entities from a common class (using custom T4 templates to generate the classes from the model). And then I can add a generic constraint to my repositories, like:
public class MyRepository<TEntity> where TEntity : MyEntityBaseClass
And then my common base class has an Id field which is inherited by all the entities so I can can simply do:
return myObjectSet.SingleOrDefault(x => x.Id == myId);
I'm sure there are other approaches, that might be a good topic for another question.
1. You want to add the DbContextGenerator template to your visual studio templates:
2. After this make sure you clear out the default generation tool on your .edmx file.
3. Now you can implement the GenericRepository pattern as you wish.
One strange thing i've got to see in Entity Framework 4.0 V2 Auto Generated Classes(tt) is that the classes are not marked as Serializable. Although they are having DataContract attribute for WCF.
Now the problem is, when I store the POCO object into viewstate it throws me an exception saying that the class is not serializable.
If I generate the classes without the t4 templates or using the defualt class generating scheme, what i see is that the generated classes are having the Serializable attribute on them.
But unfortunately i can not make use of the default Entity Generation Scheme. Since I want to accomodate some custom logic to the autogenerated class which is possible through t4 templates only.
Now what i want to know is:
1) Why the Serializable Attribute is not there in the autogenerated class or am I making any mistake or i am towards a wrong approach.
2) Is it a good idea to customize the EF 4.0 T4 template to accomodate Serializable attribute.
Looking for your valuable suggestion.
Thanks,
Burhan Ghee
Yes you can modify the template. Look at Adding [DataMember] [DataContract] attributes in Entity Framework POCO Template for exactly what you need to do to fix your template. Look specifically at the WriteHeader function in the template.
The purpose of T4 template is allow you to customize. Customize it fearlessly! You are not only encouraged to customize template, but also the edmx file that your template is based on.
see this http://blogs.msdn.com/adonet/archive/2010/03/05/updated-data-model-designer-extension-starter-kit.aspx