Home » Modeling » EMF » code generation guidance, in the interest of (my) time.
|
| Re: code generation guidance, in the interest of (my) time. [message #428008 is a reply to message #428005] |
Mon, 09 March 2009 16:44   |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Mark,
Comments below.
Mark Geib wrote:
> My team is building a system that uses the google protobuf messages
> for encoding information that is eventually persisted as EMF objects.
> The EMF model is complete, and the team is spending effort in
> confirming the protobuf attributes "match" the attributes in each EMF
> object, etc.
>
> I would like to avoid this work by generating the .proto files from
> the model directly. I can write the JET templates but I would like to
> create a new project, much like the .test project, for the protobuf
> files.
Might it be better to do it via reflection so that you don't have to
generate anything. Consider for example that the whole
org.eclipse.emf.ecore.xmi plugin does all serialization using reflection...
>
> Is following the example provided by EMF the way to proceed, or is
> there a better method for adding this to an existing EMF model
> project..? Specifically I am not sure where to create, or test for,
> the additional project.
It's less work to generate additional stuff into existing projects.
The generator example of the validator would be good to look at... But
ideally, you'd not need to generate a whack of
serialization/deserialization logic...
>
> Thanks for any help or suggestions.
> Mark.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: code generation guidance, in the interest of (my) time. [message #428013 is a reply to message #428008] |
Mon, 09 March 2009 17:05 |
Mark Geib
Messages: 432
Registered: July 2009 |
Senior Member |
|
|
Ed,
Thanks for the input.
Performance is a priority. We discussed using reflection, which led us
to the idea of generating code. We could potentially need to process
thousands of messages/sec. So what we decided on was something along the
lines of
1. receive a protobuf message or type Stick.
2. retrieve the EMF object for the the Stick of interest.
3. call StickUpdate( protoStick, modelStick );
StickUpdate, the generated helper class, would do the compare of the
attributes smartly to avoid any resource updates for Stick.
The stream of messages will contain MANY messages with data for objects
in the model with no changes...we only want to generate notifications
for "real" changes.
We wanted to avoid un-necessary pollution of the generated EMF projects.
Thats why we thought an additional project made sense..
Mark.
Ed Merks wrote:
> Mark,
>
> Comments below.
>
> Mark Geib wrote:
>> My team is building a system that uses the google protobuf messages
>> for encoding information that is eventually persisted as EMF objects.
>> The EMF model is complete, and the team is spending effort in
>> confirming the protobuf attributes "match" the attributes in each EMF
>> object, etc.
>>
>> I would like to avoid this work by generating the .proto files from
>> the model directly. I can write the JET templates but I would like to
>> create a new project, much like the .test project, for the protobuf
>> files.
> Might it be better to do it via reflection so that you don't have to
> generate anything. Consider for example that the whole
> org.eclipse.emf.ecore.xmi plugin does all serialization using reflection...
>>
>> Is following the example provided by EMF the way to proceed, or is
>> there a better method for adding this to an existing EMF model
>> project..? Specifically I am not sure where to create, or test for,
>> the additional project.
> It's less work to generate additional stuff into existing projects.
> The generator example of the validator would be good to look at... But
> ideally, you'd not need to generate a whack of
> serialization/deserialization logic...
>>
>> Thanks for any help or suggestions.
>> Mark.
|
|
|
| Re: code generation guidance, in the interest of (my) time. [message #428081 is a reply to message #428013] |
Mon, 09 March 2009 18:12 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Mark,
Comments below.
Mark Geib wrote:
> Ed,
>
> Thanks for the input.
>
> Performance is a priority.
So be sure to measure, measure, and then measure a third time.
> We discussed using reflection, which led us to the idea of generating
> code.
Do the reflection first.
> We could potentially need to process thousands of messages/sec.
Keep in mind that loading byte code isn't free and bloating the system
which huge whacks of byte code can slow things down badly. So don't
even assume that if a small test case shows generated code is faster,
that as you scale the number of models, that will still be true. It's
also likely that you'll be tuning the wrong aspect if your design
efforts are guided by actual measurements.
> So what we decided on was something along the lines of
>
> 1. receive a protobuf message or type Stick.
> 2. retrieve the EMF object for the the Stick of interest.
> 3. call StickUpdate( protoStick, modelStick );
> StickUpdate, the generated helper class, would do the compare of the
> attributes smartly to avoid any resource updates for Stick.
>
> The stream of messages will contain MANY messages with data for
> objects in the model with no changes...we only want to generate
> notifications for "real" changes.
I see.
>
> We wanted to avoid un-necessary pollution of the generated EMF
> projects. Thats why we thought an additional project made sense..
Probably it does. It's just a bit more work. I think you should
compare a reflective approach with a generated code and see whether it
really matters...
>
> Mark.
>
>
> Ed Merks wrote:
>> Mark,
>>
>> Comments below.
>>
>> Mark Geib wrote:
>>> My team is building a system that uses the google protobuf messages
>>> for encoding information that is eventually persisted as EMF
>>> objects. The EMF model is complete, and the team is spending effort
>>> in confirming the protobuf attributes "match" the attributes in each
>>> EMF object, etc.
>>>
>>> I would like to avoid this work by generating the .proto files from
>>> the model directly. I can write the JET templates but I would like
>>> to create a new project, much like the .test project, for the
>>> protobuf files.
>> Might it be better to do it via reflection so that you don't have to
>> generate anything. Consider for example that the whole
>> org.eclipse.emf.ecore.xmi plugin does all serialization using
>> reflection...
>>>
>>> Is following the example provided by EMF the way to proceed, or is
>>> there a better method for adding this to an existing EMF model
>>> project..? Specifically I am not sure where to create, or test for,
>>> the additional project.
>> It's less work to generate additional stuff into existing projects.
>> The generator example of the validator would be good to look at...
>> But ideally, you'd not need to generate a whack of
>> serialization/deserialization logic...
>>>
>>> Thanks for any help or suggestions.
>>> Mark.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: code generation guidance, in the interest of (my) time. [message #428098 is a reply to message #428081] |
Tue, 10 March 2009 14:12 |
Mark Geib
Messages: 432
Registered: July 2009 |
Senior Member |
|
|
Ed,
There is also the benefit of code re-use if we can generate a standalone
project containing the protobuf files, and resulting java classes. This
approach will allow the system producing the message to use the
generated protobuf files from the model.
We discussed here yesterday some more, and no one is against generating
the protobuf files within the model project in a new directory/folder.
However, since the protobuf files will be compiled into java it just
feels a little cleaner to create a separate project dedicated to protobuf.
The protobuf compiler generates a reflective api from the protobuf files
as well, so initially we are going to use reflection to do the compares
and updates between protobuf and EMF. We will only generate the protobuf
files from the model to start with.
So, what is the correct approach to generate a new project, then
populate the project with protobuf files from the ecore model.? Should
we just copy all the JET templates from EMF, modify and then maintain
our "special" copy.?? We would like to have the option of generating
protobuf files for any EMF model, now and in the future.
Thanks again,
Mark.
Ed Merks wrote:
> Mark,
>
> Comments below.
>
> Mark Geib wrote:
>> Ed,
>>
>> Thanks for the input.
>>
>> Performance is a priority.
> So be sure to measure, measure, and then measure a third time.
>> We discussed using reflection, which led us to the idea of generating
>> code.
> Do the reflection first.
>> We could potentially need to process thousands of messages/sec.
> Keep in mind that loading byte code isn't free and bloating the system
> which huge whacks of byte code can slow things down badly. So don't
> even assume that if a small test case shows generated code is faster,
> that as you scale the number of models, that will still be true. It's
> also likely that you'll be tuning the wrong aspect if your design
> efforts are guided by actual measurements.
>> So what we decided on was something along the lines of
>>
>> 1. receive a protobuf message or type Stick.
>> 2. retrieve the EMF object for the the Stick of interest.
>> 3. call StickUpdate( protoStick, modelStick );
>> StickUpdate, the generated helper class, would do the compare of the
>> attributes smartly to avoid any resource updates for Stick.
>>
>> The stream of messages will contain MANY messages with data for
>> objects in the model with no changes...we only want to generate
>> notifications for "real" changes.
> I see.
>>
>> We wanted to avoid un-necessary pollution of the generated EMF
>> projects. Thats why we thought an additional project made sense..
> Probably it does. It's just a bit more work. I think you should
> compare a reflective approach with a generated code and see whether it
> really matters...
>>
>> Mark.
>>
>>
>> Ed Merks wrote:
>>> Mark,
>>>
>>> Comments below.
>>>
>>> Mark Geib wrote:
>>>> My team is building a system that uses the google protobuf messages
>>>> for encoding information that is eventually persisted as EMF
>>>> objects. The EMF model is complete, and the team is spending effort
>>>> in confirming the protobuf attributes "match" the attributes in each
>>>> EMF object, etc.
>>>>
>>>> I would like to avoid this work by generating the .proto files from
>>>> the model directly. I can write the JET templates but I would like
>>>> to create a new project, much like the .test project, for the
>>>> protobuf files.
>>> Might it be better to do it via reflection so that you don't have to
>>> generate anything. Consider for example that the whole
>>> org.eclipse.emf.ecore.xmi plugin does all serialization using
>>> reflection...
>>>>
>>>> Is following the example provided by EMF the way to proceed, or is
>>>> there a better method for adding this to an existing EMF model
>>>> project..? Specifically I am not sure where to create, or test for,
>>>> the additional project.
>>> It's less work to generate additional stuff into existing projects.
>>> The generator example of the validator would be good to look at...
>>> But ideally, you'd not need to generate a whack of
>>> serialization/deserialization logic...
>>>>
>>>> Thanks for any help or suggestions.
>>>> Mark.
|
|
|
| Re: code generation guidance, in the interest of (my) time. [message #428099 is a reply to message #428098] |
Tue, 10 March 2009 14:26 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Mark,
Have a look at the org.eclipse.emf.examples.generator.validator example
as a starting point. If you have the SDK you can create the example
directly in your workspace via the examples wizard. You only need to
use dynamic templates if plan to alter what's normally generated. If
you generate additional artifacts, you can do that just like the example
illustrates. Have a look in GenBaseGeneratorAdapter's project types.
I'm not sure how easy it will be to create another project type...
Mark Geib wrote:
> Ed,
>
> There is also the benefit of code re-use if we can generate a
> standalone project containing the protobuf files, and resulting java
> classes. This approach will allow the system producing the message to
> use the generated protobuf files from the model.
>
> We discussed here yesterday some more, and no one is against
> generating the protobuf files within the model project in a new
> directory/folder. However, since the protobuf files will be compiled
> into java it just feels a little cleaner to create a separate project
> dedicated to protobuf.
>
> The protobuf compiler generates a reflective api from the protobuf
> files as well, so initially we are going to use reflection to do the
> compares and updates between protobuf and EMF. We will only generate
> the protobuf files from the model to start with.
>
> So, what is the correct approach to generate a new project, then
> populate the project with protobuf files from the ecore model.? Should
> we just copy all the JET templates from EMF, modify and then maintain
> our "special" copy.?? We would like to have the option of generating
> protobuf files for any EMF model, now and in the future.
>
> Thanks again,
> Mark.
>
>
>
> Ed Merks wrote:
>> Mark,
>>
>> Comments below.
>>
>> Mark Geib wrote:
>>> Ed,
>>>
>>> Thanks for the input.
>>>
>>> Performance is a priority.
>> So be sure to measure, measure, and then measure a third time.
>>> We discussed using reflection, which led us to the idea of
>>> generating code.
>> Do the reflection first.
>>> We could potentially need to process thousands of messages/sec.
>> Keep in mind that loading byte code isn't free and bloating the
>> system which huge whacks of byte code can slow things down badly. So
>> don't even assume that if a small test case shows generated code is
>> faster, that as you scale the number of models, that will still be
>> true. It's also likely that you'll be tuning the wrong aspect if
>> your design efforts are guided by actual measurements.
>>> So what we decided on was something along the lines of
>>>
>>> 1. receive a protobuf message or type Stick.
>>> 2. retrieve the EMF object for the the Stick of interest.
>>> 3. call StickUpdate( protoStick, modelStick );
>>> StickUpdate, the generated helper class, would do the compare of the
>>> attributes smartly to avoid any resource updates for Stick.
>>>
>>> The stream of messages will contain MANY messages with data for
>>> objects in the model with no changes...we only want to generate
>>> notifications for "real" changes.
>> I see.
>>>
>>> We wanted to avoid un-necessary pollution of the generated EMF
>>> projects. Thats why we thought an additional project made sense..
>> Probably it does. It's just a bit more work. I think you should
>> compare a reflective approach with a generated code and see whether
>> it really matters...
>>>
>>> Mark.
>>>
>>>
>>> Ed Merks wrote:
>>>> Mark,
>>>>
>>>> Comments below.
>>>>
>>>> Mark Geib wrote:
>>>>> My team is building a system that uses the google protobuf
>>>>> messages for encoding information that is eventually persisted as
>>>>> EMF objects. The EMF model is complete, and the team is spending
>>>>> effort in confirming the protobuf attributes "match" the
>>>>> attributes in each EMF object, etc.
>>>>>
>>>>> I would like to avoid this work by generating the .proto files
>>>>> from the model directly. I can write the JET templates but I would
>>>>> like to create a new project, much like the .test project, for the
>>>>> protobuf files.
>>>> Might it be better to do it via reflection so that you don't have
>>>> to generate anything. Consider for example that the whole
>>>> org.eclipse.emf.ecore.xmi plugin does all serialization using
>>>> reflection...
>>>>>
>>>>> Is following the example provided by EMF the way to proceed, or is
>>>>> there a better method for adding this to an existing EMF model
>>>>> project..? Specifically I am not sure where to create, or test
>>>>> for, the additional project.
>>>> It's less work to generate additional stuff into existing
>>>> projects. The generator example of the validator would be good to
>>>> look at... But ideally, you'd not need to generate a whack of
>>>> serialization/deserialization logic...
>>>>>
>>>>> Thanks for any help or suggestions.
>>>>> Mark.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:35:00 GMT 2024
Powered by FUDForum. Page generated in 0.03408 seconds |
] 
Search
Help
Register
Login
Home
