|
|
|
Re: Two DSLs or two-tier-build? [message #1842939 is a reply to message #1842937] |
Wed, 07 July 2021 07:49 |
Konrad Jünemann Messages: 93 Registered: December 2018 |
Member |
|
|
Hi Ed,
well, they are similar regarding how imports, "java-docs" and "annotations" are handled (both DSLs share those concepts). They furthermore share many similarities regarding their UI (handling of hover, ...) and many things behind the scenes, e.g, caching. So yeah, the grammars are different, but their metamodels share a common abstract metamodel, also much code is shared.
(should note: I usually define the metamodel myself instead of letting it be generated. So both DSL's metamodels use a common-MM, which defines shared stuff.)
Still my question remains: is it possible to generate .mydsl-files from another .mydsl-file in such a way that the generated .mydsl file will be parsed instantly?
|
|
|
|
|
|
|
Re: Two DSLs or two-tier-build? [message #1843332 is a reply to message #1842946] |
Fri, 23 July 2021 15:48 |
Konrad Jünemann Messages: 93 Registered: December 2018 |
Member |
|
|
OK, I finally got to look into this some more. First good news: there seems to be indeed no reason to use two DSLs. I made it work with just one, although I am currently still "touching" the freshly generated mydsl files in order to trigger another run of the builder.
Then I looked into IDerivedStatecomputer as Christian proposed. I looked into Christian's cast and into Lorenzo's book.
If I understand the DerivedStateAwareResource correctly the state is updated just when the resource itself is updated - so the state must not contain any information from beyond the resource itself, so no information stored in linked EObjects may be used. This makes the IDerivedStatecomputer unfeasible for my needs, if I understood it correctly, as in my case Entities may refer to each other and this linked information might be needed when generating the tables.
Also I would like the use to be able to create Tables manually, which should then of course also generate to correct SQLs.
Let me try to explain a bit: business entities reference each other. Also, there is a n to m relationship between entities and their generated tables: for some entities multiple tables have to be generated and for some tables multiple entities have to be accessed in order to generate them.
In order to be able to compile all that stuff incrementally, I form "buckets" of entities (according to some rules) which should compile together. I extended the IGenerator interface following one of Karsten's (? I think) blog posts, so that the generator is just called once for each bucket.
When looking at the following example, entities A and B are part of the same bucket, while entity C has its own bucket. From bucket one, tables T1 and T2 shoudl be generated, while T3 to T5 are generated from entity C. T6 is manually defined. (In reality its even a bit more complicated, as entities might belong to multiple buckets at the same time.)
€: Forgot to say: Each entity resides in its own file / resource.
___ ___ ___
|A| |B| |C|
___ ___ ___
|______| |________ manually defined:
| | |
T1 - T2 T3 - T4 - T5 T6
| | | | | |
SQL SQL SQL SQL SQL SQL
Now, how would I store the derived tables in the DerivedStateAwareResource? If I put, say, T1 in A's resource, it would not be refreshed when B changes. Did I misunderstand you?
I think I will just try to make my generator work in two phases:
1. Generate all tables for the bucket
2. Pass those buckets straight to a second Generator that derives SQLs for them. This second Generator can also be called for manually generated Tables.
3. (optional): serialize the generated tables to the disk, but without triggering the builder again. This could be usefull if the user wants to inspect the tables himself, spectate them in outline view etc.
I think this approach should work nicely? Let me know if you think this is complete rubbish.
;-)
[Updated on: Fri, 23 July 2021 15:50] Report message to a moderator
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04372 seconds