Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getGoodsDeliveryLines #655

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

mizbanpaytakht
Copy link

No description provided.

@remkobrenters
Copy link
Collaborator

Before it can be merged can you fix the missing newline (see ci check)

@remkobrenters
Copy link
Collaborator

@DannyvdSluijs not sure if it is a stupid question but do you think it is possible to auto generate the getters for the child collection items? Or is there something different between the various models and their relations making this a piece of logic that needs to be added on a per-model situation?

@DannyvdSluijs
Copy link
Contributor

@DannyvdSluijs not sure if it is a stupid question but do you think it is possible to auto generate the getters for the child collection items? Or is there something different between the various models and their relations making this a piece of logic that needs to be added on a per-model situation?

That is actually a good suggestion. At this point I’m not sure if this can be done easily. I do know that non generated code is being kept when regenerating. So there is nothing blocking adding an additional getter as a short term fix.

When I have time available I can look into the generating code and see if we can add collection getters.

One other idea I’m having (but struggling to find the time for) is to have the manual work I do frequent updates turned into a GitHub workflow.

@remkobrenters
Copy link
Collaborator

Get it. Understand it is a bit hard to find the time for this. Was more thinking out loud based on this stalled PR.

@DannyvdSluijs
Copy link
Contributor

@remkobrenters I've been playing around with this idea as you triggered me. One thing I came to realise, is the info that is needed to generate the correct code consists out of the following:

  1. The fact that it is an internal relation, this can be done based on the lack of en EDM. prefix from type value taken from the EOL documentation
  2. The corresponding model, this should also be doable from the type value
  3. The type of relation, is it a one-to-one, one-to-many (or even a many-to-many if that is possible?). Perhaps we can still derive this in an automated way
  4. How to specify the correct filter expression (e.g. "EntryID eq guid'{$this->EntryID}'") this is where I am stuck ATM.

So this is me giving a status update and not seen an easy solution. So perhaps you can think of something or internally check if there is an "expert" on the deferred properties?

One final piece of info that I just ran into is commit f527c4f, adding a protected lazyLoad method)which might also be an option to explore. But that requires me to setup a proper client id/secret which I don't have at this point.

Eager to hear your thoughts.

@remkobrenters
Copy link
Collaborator

I think we should be able to join your thoughts about this but we are in a bit of a hectic time here for the upcoming weeks. I will discuss this and we will take a crack at this as it feels it is very possible to automate this in a good way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants