Editor does not update primary table when using LeftJoin()

fabiomoggi

Hi there

I noticed that Editor is not updating my primary table when using LeftJoin(), it simply ignore the change. Interesting that Datatables for .NET does not throw any exception, indicating that it may be a code issue. Then I started to debug and realized that it never runs the following code inside method private Result _InsertOrUpdateTable

var fieldPart = _Part(field.DbField(), "field");
                set.Add(fieldPart, field.Val("set", values));

As an effort to figure out what was going on, I decided to manually add the primary table name to the field variable and it worked.

However, I still don't know how to permanently fix this.

I investigated this forum for similar question but could not find an answer to it.

Basically, I created two tables on SQL Server:

Table Transaction: id, amount, vendorId
Table Vedor: id, name

C# Transaction Controller:

        [Route("api/transaction")]
        [HttpGet]
        [HttpPost]
        [EnableCors(origins: "*", headers: "*", methods: "*")]
        public IHttpActionResult Transaction()
        {
            var request = HttpContext.Current.Request;
            var settings = Properties.Settings.Default;

            using (var db = new Database(settings.DbType, settings.DbConnection))
            {
                var response = new Editor(db, "Transaction")
                    .Model<TransactionModel>()
                    .TryCatch(false)
                    .LeftJoin("Vendor", "vendor.id", "=", "Transaction.vendorId")
                    .Field(new Field("vendor.name"))
                    .Process(request)
                    .Data();

                return Json(response);
            }
        }

Thanks very much for the support

allan

What you say the "primary table", do you mean it isn't modifying the "Transaction" table?

Could you show me both your TransactionModel and also the Editor Javascript initialisation please?

Thanks,
Allan

fabiomoggi

Hi Allan,

Thanks for the support once again.

I was able to fix this by creating a Join class that encapsulates Transaction and Vendor objects - just like the manual says. However, this approach does create conflict with relational data concept. I was expecting to be able to design business objects as separete entities and then join them by class attributes - something like Transaction.Vendor.name or Transaction.Payment.creditcardnumber.

I am sure this is just matter of changing my mindset to design different architecture to fully take advantage of Editor.

allan

Hi,

Great to hear the manual helped.

For my interest, might you be able to expand upon your example with class attributes a little? Is that more common in the .NET world than the approach I've taken?

Thanks,
Allan

fabiomoggi

Well, the issue I see with your approach is that I am obligated to use embedded classes to represent nested data. This is more common when designing for non-relational database systems as it facilitates generating document-based responses such as JSON files.

The project I am working in has the following class objects:

BankTransaction
Vendor
Category
Payment

I would then define BankTransaction:

public string id { get; set; }
public Vendor vendor { get; set; }
public Category category { get; set; }
....

The approach Editor takes does not truly connect the objects, instead, it has an integer vendorId, categoryId, paymentId that maps the database foreign keys.

There is no right or wrong approach, I guess, it is just how my mind is used to design systems. Still, Editor is a great framework and I am playing around to make sure it will support my ideas.

As always, thanks for the quick support, Allan.

fabiomoggi

I had posted issue, but I was able to fix it

allan

I see - so basically it is the nested classes that don't work for you. I did it that way to try and make it easy to write a model that uses join information specifically for Editor. I can see how modals that are also used outside of Editor aren't going to work particularly well with this. I'll do some thinking for future releases to see how I can address that. Possibly the Model() method could be called multiple times with different models and a "table" identifier as a second argument.

Allan

fabiomoggi

Putting some thought on this, I realized I should actually decouple the Model layer into two other layers:

DTO Layer - contains nested classes that directly maps JSON responses used in Editor.

Model Layer - contains business objects that will be used outside of Editor.

• I need to come up with better names to these two data layers.

Example:

1) BankTransactionController will instanciate a new Editor class and set Model<BankTransactionDTO>()

2) BankTransactionDTO inherits from class BankTransactionModel, in which inherits from Editor

3) BankTransactionModel can also be used outside editor and have its own custom methods to query database for example.

The main issue I want to avoid with this approach is to declare the same class object more than once, under different JOIN classes. Let's say I need a join between BankTransaction and Billing, then a join between Payment and Billing. Most likely I would not be able to reuse Billing class because they necessarily need to be declared under each join class so that Editor can automatically generate the response based on the class definition.

Not sure if I made myself clear at all

allan

Yup - that sounds good, although it sounds like it might reduce some redundancy. If is is possible to use the Model Layer classes directly with Editor (even if its only specific parameters, perhaps signalled via attributes) that would seem to be the simplest approach?

Allan