uploadMany without Mjoin
uploadMany without Mjoin
I am trying to implement uploadMany without using recommended link table and Mjoin class. The reason is that I have several separate uploadMany fields in main table. This would require separate link table for each field I guess.
I have tried this approach: https://datatables.net/forums/discussion/61382/is-it-possible-to-use-uploadmany-without-join#latest
This approach uses get/set formatter to implode/explode array of id's into string stored in main table field. At first look it seems to work.
But i have came into the same trouble: I can upload, save record but not edit, because "files" in json server response doesn't contain all files needed, only the first one.
I have found that reason for this is how db() method works. It takes raw value of editor field as stored in database (string) without formatters and uses this value in IN clause to return info about files stored in that field. The query looks like this:
SELECT id .... FROM files WHERE id IN "1|2|3"
SQL tries to convert "1|2|3" to integer, which is 1, so this query returns only the first file.
Any ideas? @yokowasis how did you solve this?
Tested on Editor 2.4.1
This question has an accepted answers - jump to answer
Answers
Hi,
As you've found, there are paths in the server-side code that would require modification for this to work I'm afraid. They are (as I recall) optimisations so it is possible that if someone had this working before, it was with an old version.
I'm trying to think if it would be possible to use a single link table - would that be suitable for your needs if so? It would probably need to have a condition applied to an extra column to indicate which field it belongs to.
Allan
Hi Allan,
thanks for reply. Having extra column in link table would probably solve my issue. I was wondering if that isn't already possible with Mjoin class, but probably not.
But that inspired me doing this on files table instead: having extra column set in db() method to some static value (different for each field) and then using where() method of Upload class. Of course, this requires that one file is used only for one field, but that's ok. What you think?
I need to test it, but at the same time I am struggling with deleting files from uploadMany field: all files can be deleted just fine but the last one. Leaving field empty doesn't send that field to server on update at all. So server doesn't set it to null. I have checked in debug console, the uploadMany field is not in UPDATE clause.
But maybe using link as proposed will resolve this bug as well.
I have tried many ways, but I can't make it work to have multiple uploadMany fields in one editor, using only one files table and one link table.
While Mjoin always refers to joined table name (sends data to client under this name) and cannot be aliased, there is no way tell which one is which if you use more that one Mjoin to the same table.
I achieved promising results with aliasing field inside Mjoin, but it sometimes breaks sql syntax.
The only way seems to have separate file and link table for each uploadMany field. This will be probably a mess in database. The only other solution would be going back to idea of not using Mjoin, store files ids array as imploded string in main table and writing some extra php to manage this properly.
Any ideas?
Apologies, I'd hoped to work on this today, but I had to look into some other stuff. I hope to do so on Monday.
Allan
Hi,
I've just been investigating this, and unfortunately there isn't going to be an easy way to do this. There are various hooks and things that hint in that direction, but there isn't anything that quite gets us all the way there. What is really needed is better control over the link table, so we can apply conditions and write values to it. That would resolve this issue immediately. Unfortunately at the moment the only way to do is is a table with Mjoin.
I've been thinking about better control for the link table for a while, and this has helped me to firm up my thoughts for it.
Sorry I don't have better news at the moment - multiple tables is the way to do it for now.
Allan
Thanks Allan, I can see complexity of this and maybe my use case is not very common. But anyway, from what I know from real-world applications, having possibility to give link table entries specific values, alias that table etc. opens up another dimension in 1:N and N:M relations.
For now I will stick with separate tables. But I'll be happy if you share some thoughts or progress on this or need some tester
br, Juraj
Hi Juraj,
Thanks! I've got a link to this thread in the issue I'll use to track this feature. Can't say for sure when it will be, currently arranging next development priorities.
Allan