Currently Issues with Mapping (Mapperly), in debug mode when call made to API it exits
Repo:
https://github.com/Mozin0/ProjectManagement/tree/main/ProjectManagement
SubTasks mapping doesnt work and its all very weird.
GitHub
ProjectManagement/ProjectManagement at main · Mozin0/ProjectManagem...
Contribute to Mozin0/ProjectManagement development by creating an account on GitHub.
43 Replies
@🍦 viceroypenguin | 🦋🐧🌟 When you can :catpat:
well yeah, you're declaring a recursive type. of course it's going to show
"string". if it tried to show the type again, then it would be an infinite loop of subtask definitions
if you send it the right json, ti'll work fine
just ignore the ["string"] there because that's how swagger is avoiding the infinite loopahh okay
in my database i have a task and a subtask as u can see, also represented by ParentTaskId
i did these manually
Whenever i try to get tasks in debug mode my program exits
without any subtasks my tasks get works but when a subtask is refering to its parent task thats what happens
i'd look at the code that mapperly is generating. probably isn't compatible with a true recursive type
how do i have access to it?
dang, you really pissed of your VS, didn't you
xDD weird
vs code* 😛
oh, /shrug
i don't touch VSC
the mapperly file opens just fine for me in VS
ewww.....
ITaskManager?
and using block scoped namespaces?
are we in 2010? please stop
public IQueryable<ProjectTaskDto> GetTasks() - no. just no. do not do this
so the root problem is that you're using non-Expressions to try and convert db queries to C# models
don't do that
also, querying recursive data types from the database requires some unique magic. i don't even know if EFC can do that magic. (since i don't use EFC)
you should look up EFC recursive CTE
i know that you can do it when you bolt on linq2db.entityframeworkcore library, and use the l2db query engine to do it.
[HttpPut("{parentId}subtasks/{id}")] invalid urlwats wrong with the interface xD
$whynotca
CA is not necessarily difficult to understand conceptually, but they're difficult to build and difficult to maintain. When you build a real project, you will quickly (as often evidenced on this server) run into questions like "Is this an infrastructure object or a domain object?" or "Should I implement this contract in the infrastructure or the application?". Questions that a) take your time to ponder and ultimately answer, and b) distract you from doing your actual work.
It also adds unnecessary abstractions, by forcing you to use layers: both unnecessary layers and unnecessary decoupling between layers. For example, CA would generally argue that you should abstract the database into repositories and services should depend on an interface for the repository. However, modern ORMs like EFC already implement the repository pattern, by abstracting the implementation of a query via LINQ. Furthermore, in most applications, there's only one implementation of
IXxxRepository - so why create the interface abstraction?
Instead, it's generally better to get rid of nearly all interfaces, keeping only ones that truly have more than one implementation; simplifying maintenance because any change to an api only needs to be done in one class instead of both class and interface. Smush all of the code down into a single Web project, or possibly two: Web and Services projects; removing any questions about "which project does this class go into?". Organize your code well in the Web project, with all of the User-related services/controllers/models/etc under /Features/Users/Xxx; all of the Order-related services/controllers/models/etc under /Features/Orders/Xxx; etc. Then it will be easy to find and maintain all of the code related to such and such feature. Any Infrastructure code (like emails, behaviors, startup code, etc.) can go under /Infrastructure/Xxx, and any non-infrastructure code that's not related to a feature can go under /Features/Shared.I guess i still have things picked up from school xD
I thought this was recommended with Dto's instead of Ienymerables
no, abso-fucking-lutely not
passing around
IQueryable<>s is asking for trouble, and you should not ever do it.
only time you can use IQueryable<> is if you're creating a query inside of a class. it should always be materialized before leaving the class
aka any public method should only use IEnumerable, List, etc.Oops thats right just a single statement should do
got it ill change to expressions
viceroypenguin
also, querying recursive data types from the database requires some unique magic. i don't even know if EFC can do that magic. (since i don't use EFC)
Quoted by
<@294961273458655232> from #Currently Issues with Mapping (Mapperly), in debug mode when call made to API it exits (click here)
React with ❌ to remove this embed.
from what ive researched quickly just now, looks like EFC doesnt support CTE
then use l2db.efc
and don't use mapperly for that
https://linq2db.github.io/articles/sql/CTE.html
is ADO.net needed for this? it says so in the get started but if i remmeber correctly ADO.net is for raw sql and isnt it a bit outdated?
oops yes it is forgot the /
slight distinction here:
* ado.net is the foundation for everything db related undera ll systems, so definitely not a "not needed"
* but definitely don't use ado.net directly anymore, because it's outdated
but that's eht point of the article i sent you. use linq2db.efc and you can write recursive queries in linq instead of raw sql
hmm that makes sense, would i scrap my use of mapperly since project and tasks & subtasks have a connection, or is it possible to keep it for project and tasks
also you never said why this was ew
i did. you interpreted correctly, that it was because it's an interface.
you might be able to keep fro projects, but probably not
that sucks so would it have to be manual mapping then
i thought interfaces was a good thing? to offer abstraction where possible
MODiX#0152
CA is not necessarily difficult to understand conceptually, but they're difficult to build and difficult to maintain. When you build a real project, you will quickly (as often evidenced on this server) run into questions like "Is this an infrastructure object or a domain object?" or "Should I implement this contract in the infrastructure or the application?". Questions that a) take your time to ponder and ultimately answer, and b) distract you from doing your actual work.
It also adds unnecessary abstractions, by forcing you to use layers: both unnecessary layers and unnecessary decoupling between layers. For example, CA would generally argue that you should abstract the database into repositories and services should depend on an interface for the repository. However, modern ORMs like EFC already implement the repository pattern, by abstracting the implementation of a query via LINQ. Furthermore, in most applications, there's only one implementation of
IXxxRepository - so why create the interface abstraction?
Instead, it's generally better to get rid of nearly all interfaces, keeping only ones that truly have more than one implementation; simplifying maintenance because any change to an api only needs to be done in one class instead of both class and interface. Smush all of the code down into a single Web project, or possibly two: Web and Services projects; removing any questions about "which project does this class go into?". Organize your code well in the Web project, with all of the User-related services/controllers/models/etc under /Features/Users/Xxx; all of the Order-related services/controllers/models/etc under /Features/Orders/Xxx; etc. Then it will be easy to find and maintain all of the code related to such and such feature. Any Infrastructure code (like emails, behaviors, startup code, etc.) can go under /Infrastructure/Xxx, and any non-infrastructure code that's not related to a feature can go under /Features/Shared.Quoted by
<@294961273458655232> from #Currently Issues with Mapping (Mapperly), in debug mode when call made to API it exits (click here)
React with ❌ to remove this embed.
It also adds unnecessary abstractions, by forcing you to use layers: both unnecessary layers and unnecessary decoupling between layers. For example, CA would generally argue that you should abstract the database into repositories and services should depend on an interface for the repository. However, modern ORMs like EFC already implement the repository pattern, by abstracting the implementation of a query via LINQ. Furthermore, in most applications, there's only one implementation of IXxxRepository - so why create the interface abstraction? Instead, it's generally better to get rid of nearly all interfaces, keeping only ones that truly have more than one implementation; simplifying maintenance because any change to an api only needs to be done in one class instead of both class and interface.namely, it's unnecessary and increases the work that you have to do to maintain your code
That makes sense actually
Tbh i found it useless but just thought thats wat was best and CA
yeah, don't do CA
so do i abandon mostly everything that was taught in schoold cos it was outdated xD, we even was taught how to use ado.net n that was 2-3 years ago
I will refactor n add things in my code and @ you when I've done them
this is just for the Get method but i managed to do it using the package u suggested, thank you
I will still keep this open incase i struggle with other methods etc tmrw
EF can do it fine as well
ThenInclude is filling the subtasks here.
what about y.SubTasks.SubTasks?
then u would need another ThenInclude is my understanding as depth goes
if u mean a way to naturally transverse it
yeah, that's the problem
without having to specify depth
with a recursive dataset, to properly go all the way down, you need a recursive cte
i love them, but EFC doesn't support them natively
yeah indeed
@viceroypenguin | 🦋🐧🌟 I assume u can probably cook something up that can go any depth thou...
like a extension method u specify the depth
but yeah it would be nice if it would have recursive CTE
either way this is a good learning curve for me, learning a new library and how it can work alongside EF
Firstly id limit it to a task has subtasks, then I'll see if there is a use for subtasks to have subtasks
yep is it a good learning regardless because you will get to understand about recursion and its pitfalls in db
exactly 😛