Looking to contribute about beef HOT 6 CLOSED

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 Beef.Database.Core equivalency. The DbUp functionality would be relatively straight forward as it already supports, but the stored procedure gen, etc. would require the most effort. Is this what you are proposing?

More than happy to chat more. Cheers...

from beef.

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

from beef.

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...

from beef.

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

from beef.

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 INFORMATION_SCHEMA schema. Trying running this for postgres.

The steps to codegen for me start with creating an example of what good looks like before turning into a template.

Cheers...

from beef.

Thank you mate, Ill start in these places as advised. cheers

from beef.