Open MaxOstrowski opened 1 year ago
@MaxOstrowski I think it does make sense to view the factbase/query stuff separately to conversion to clingo. There have been a number of cases where I've used clorm in a non-ASP related setting because I wanted to use the query mechanism, rather than create some messy data-structure.
But I don't have a clear idea about what the best way would be to separate the two, so I'll try to address your comments in point form as I think there are a few things to consider:
Firstly, I'm not currently aware of any other ORMs that could be used to replace the clorm factbase/querying stuff.
where(P.a.b.c.d == 5)
. AFAIK you can't do this with normal SQL. I think this is really useful for mapping to ASP facts with complex terms, so I think any replacement system would need to have the features to support this.So, secondly, unless we find some existing ORM that we can use then it comes down to seeing if it is possible to separate these two aspects of clorm. My main thought here would be to start a new project that looks at how to provide a factbase/query mechanism for something like Python dataclasses.
P.a.b.c.d
in a query P.a.b.c.d == 5
). Could possibly have a class decorator for a dataclass that generates them.
Anyway, hopefully the above makes some sense.
Your comments actually sound awesome and make perfectly sense. I am not very familiar with most ORM systems, and the nested structure you describe is definitely a plus. I think a lot of ORM's support any database, including in-memory ones, so this shouldn't be a problem. The advantage of an external database system would of course be speed and maintenance, as you do not have to write all the query stuff again - and there is a lot of sql trickery out there. In a perfect world it would be possible to map the field path objects down to flat tables efficiently. I do not know if this is possible at all. If yes, using an existing system might make sense. Otherwise I like your idea of splitting clorm into the factbase/query stuff and the conversion to clingo facts. But I think thinking about the extra bits to map whatever objects to clingo facts should be the first step. If this can't be done efficiently, then the only advantage of this whole rewriting would be for projects where you use clorm but not clingo (as you said. I've done the same :smile: ).
I like using clorm a lot, and it simplifies a lot of steps that I need to do on a daily basis, thanks.
I recently found a new viewing angle to clorm which for me basically splits this project in two parts. One is the awesome query language that operates on a database of python objects. The other functionality is to convert such a database to clingo terms (and the other way around, convert a model or instance - into python objects). Do you think this view makes sense? Do you think it makes sense to use already existing ORM systems for the first part and only provide a mapping to clingo objects if needed ? S.t. clorm + ORM system X has the same functionality as before, but the maintenance of the ORM and query stuff is with the external ORM system.