Looking to contribute #117
Replies: 7 comments
-
|
Hi @nigel-dewar, almost missed this as you opened and closed. I am open to PRs to Beef for sure (where they obviously make sense and move the capabilities forward). For the code-gen config - to be honest not really considered anything beyond the XML, and more recently JSON/YAML. These provide a technology agnostic means to describe, there are many tools than enable editing, and then are easily consumed for code-generation. They also have a benefit of being somewhat terse and relatively easy for us to consume as humans. I'd be curious as to what it would look like as fluent. Before coding it up proper I would want to see how it would look to ensure it is viable and feels natural. Then I think it would be relatively simple to code-gen it up similar to what I have now for the XML/JSON schemas - this would mean there is one means to define internally, and multiple generated means to consume externally. PostGres is something I am very keen on. In some ways it would be relatively easily supported by using the built in EF runtime support. However, there is a lot more work involved in getting More than happy to chat more. Cheers... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @chullybun , Yes sorry I opened and closed as I saw the discussions area and thought I would pop this question in there later. ( And you found this close issue sooner than I expected, hahah ). I totally understand the reasoning now on the YAML, XML templates, true that, it does make it technology agnostic and that helps me understand where you are taking this framework. What I can perhaps do is build a small sample of what I had in mind as towards a "Fluent" api. My take on it would be that the fluent api library would be a "plugin" as much as say https://github.com/StackExchange/Dapper/tree/main/Dapper.Contrib "Dapper Contrib" is for Dapper. This would allow a developer to "add-on" the fluent functionalities "only" if the want to. You might call this plugin the "Beef Sauce" or something like that or Beef Contrib. You don't need it. You can do just fine without it, but if you want some sugar on top when comes to configuring the code gen for the the entities and database gen, then you might use this plugin. The Fluent API plugin would need to be versioned accordingly against each version of beef. As said, I think its a good idea if I provide a sample POC and you can eval if it works and makes sense. It may be a completely dumb idea, but a POC will show it up if so. It may be just the case that since I'm a noob to beef the concept of defining everything in YAML or XML is just foreign to me, and that I miss the overall intent. YAML and XML is straight forwards, and ya know as they say, "key to sophistication is simplicity". Folks often end up over-complicating things, perhaps what I propose is just that, but I'm just curious to see if a fluent API might work. With PostGres, yes indeed the Stored Proc gen is specifically what I had in mind, and yes it would require much effort which is specifically where I would like to contribute. cheers |
Beta Was this translation helpful? Give feedback.
-
|
Hi @nigel-dewar. Beef Sauce - hahaha, like it. I still think this in and of itself is a candidate for code-gen similar to what is there for the XML schema. This way we would largely avoid versioning issue. There would need to be some other changes to code-gen as it is dependent on the config files existing to function; so this fluent capability could update these files and the rest would function largely as-is. Hmm. Again, would be good to see the proposed fluent to see if it is better than the XML/JSON/YAML. Are we fixing something that is not broken? What is the potential benefit? As stated, PostGres sounds really appealing. The stored procedure gen will be fun, but will take time to develop out all the equivalent handlebars templates. Cheers... |
Beta Was this translation helpful? Give feedback.
-
|
G'day @chullybun , ya know the more I use the XML config the more I see what you mean. It works really well, and although initially it may seem rather foreign, it makes sense. And yeah, it prob is just trying to fix stuff that aint broken too. Since the Postgres is an addition that will extend the frameworks capabilities I will just focus on that. Truth be told its the functionality that I also want most too. I started looking through the code again tonight, and I'll likely spend several nights debugging around to get a rudimentary understanding of what is happening. If you have any tips and tricks, and insights to shorten my journey that'd be great if you could please share. At this stage, I'm starting from the Sample CodeGen and working down from there. If this is the wrong place to start, please let me know.
And I did notice the awesome suite of tests as well, so Ill be spending alot of time studying these. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
Hi @nigel-dewar, In terms of codegen for postgres - the best place to look is at the existing templates. To understand how the codegen works look at this. For it to work against a database it also needs to interpret the database, which it does by querying the database - see here - this in theory should work against a postgres db as it uses the The steps to codegen for me start with creating an example of what good looks like before turning into a template. Cheers... |
Beta Was this translation helpful? Give feedback.
-
|
Thank you mate, Ill start in these places as advised. cheers |
Beta Was this translation helpful? Give feedback.
-
|
Hi @nigel-dewar, it has been a while; not sure how far you got with this. The pattern for introducing new database providers has now been implemented to somewhat simplify this task. This has been part of the changes Beef is currently going through on a new major version 5.x. Beef will now offer support for SQL Server and My SQL (limited). |
Beta Was this translation helpful? Give feedback.
-
Hi team, I work with Dan and Marko.
I'm looking to make some contrib PRs to this amazing framework. The first PR I was looking to make is for an extension methods lib for the CodeGen config.
What I mean is, I find the config using YAML and XML strange, and I am wishing to provide a Fluent API style config setup as you find with things like EF fluent API, or LINQ etc.
Are you open to this idea? And, before I start, do you think it would work?
I ask this because there must have been a very good reason why you opted to used YAML, XML as means of defining the Entity configuration for GodeGen and DatabaseGen. Can you see any reason why this feature I am proposing to submit as PR would not work?
In addition to the FluentApi feature, I am planning on building a PostGres implementation as well on the DatabaseGen. I realize the majority of users of Beef would typically use SQL Server, but for personal reasons I feel a PostGres plugin/feature would also be a nice addition.
With these kind of features, would you prefer these be submitted, or would you prefer I create a FORK and implement there, and provide a means for you to properly evaluate first?
Final comments... Beef is Amazing! I look forward to making meaningful contributions to this next level framework. To Eric, you are an elite programmer mate. I learnt a lot reading your code and look forward to learning a lot more. Beef is honestly something I have been looking for a long time, and I'm glad I finally found it.
Cheers
Beta Was this translation helpful? Give feedback.
All reactions