Hi again Lukas, So, I've hit a bit of a wall. I'm not able to get the POJO type correct for my mapper method, which may not be a huge deal, since there's only one column/attribute that I need to mess with to make sure it contains a valid value, but making this "just work" would be a lot easier than refactoring that logic out somewhere else.
This is the error I'm seeing: [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/ImageService.java:[32,8] com.lumos.service.ImageService is not abstract and does not override abstract method mapper() in com.lumos.service.BaseService [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/ImageService.java:[102,48] mapper() in com.lumos.service.ImageService cannot override mapper() in com.lumos.service.BaseService [ERROR] return type org.jooq.RecordMapper<com.lumos.db.tables.records.ImagesRecord,com.lumos.db.tables.pojos.Images> is not compatible with org.jooq.RecordMapper<org.jooq.Record,com.lumos.db.tables.pojos.Images> [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/ImageService.java:[101,3] method does not override or implement a method from a supertype [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/GalleryService.java:[29,8] com.lumos.service.GalleryService is not abstract and does not override abstract method mapper() in com.lumos.service.BaseService [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/GalleryService.java:[150,54] mapper() in com.lumos.service.GalleryService cannot override mapper() in com.lumos.service.BaseService [ERROR] return type org.jooq.RecordMapper<com.lumos.db.tables.records.GalleriesRecord,com.lumos.db.tables.pojos.Galleries> is not compatible with org.jooq.RecordMapper<org.jooq.Record,com.lumos.db.tables.pojos.Galleries> [ERROR] /home/devin/projects/lumos-gallery/gallery/src/main/java/com/lumos/service/GalleryService.java:[149,3] method does not override or implement a method from a supertype Here's the pertinent code: https://gist.github.com/dhoss/09a3e3a074e975a91e9274a027b12d2c A few things: 1. The suggestions you gave me concerning the generic types seem to be okay, or at least they're covered up by this error. 2. I've only tested this on the GalleryService class so I don't have to do a lot of back and forth on the code for multiple classes, and I've only made the bare minimum code adjustments for both the ImageService and GalleryService classes to properly subclass the BaseService class, so my apologies if there is a lot of comment clutter and redundant code at this point. 3. I thought it might be easier to just extend the DAOImpl class like you suggested, but I'm still left with figuring out how to shoe-horn in sorting and such, so I don't think that's a viable route at this point. I would, however, be more than happy to help contribute sorting and limiting conditions if that's on the future TODO list. 4. A slight tangent, but looking at my code I think it would be nicer to have an interface the lays out the CRUD contract, gets implemented in a CRUD base class, and then subclassed as needed. My hope would be to make my database CRUD a good deal more encapsulated and lighter weight, and allow me to have things like a cache service that's still a service but completely unrelated to the database CRUD operations. I'm probably just thinking out loud, but if that makes any of this simpler, please let me know your thoughts. I am certainly not adverse to doing something else for my mapping code. I really just need to have the GALLERIES.COVER_PHOTO get set to either the value in the database or the default cover photo, which I suppose I could just set by default when inserting the record, so there's a value for that column in the database. Either way, I would appreciate your thoughts. Thanks, -Devin On Thursday, May 19, 2016 at 12:27:34 AM UTC-6, Lukas Eder wrote: > > > > 2016-05-18 18:59 GMT+02:00 Devin Austin <[email protected] <javascript:> > >: > >> >>> The simplest way forward might be to extend the default DAOImpl and let >>> the code generator use your custom DAOImpl as a base class using generator >>> strategies: >>> >>> One option using generator strategies would be to implement "custom code >>> sections", where you can add your own methods to the generated DAOs: >>> >>> http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy >>> >>> Another option would be to extend the generated DAOs and add >>> functionality on a per-table basis. >>> >>> But of course, your suggested option is fine, too. >>> >>> >> Extending the generated DAOs might not be so bad. I'll read up on what >> you've sent me, thanks! >> > > Alright. Let me know how it goes, and if you encounter any issues. > > In terms of my last question, regarding the TABLE object (I'm afraid I >> don't know a better term for it), if you look here: >> https://gist.github.com/dhoss/539650094085c2ef152acab6d5884a0d#file-baseservice-java-L24, >> >> you'll see I've got pseudo code attempting to try and fulfill a generic >> table object for the query. Normally, instead of TABLE, it would be a >> specific table object name generated by jooq, like GALLERY or IMAGE, in my >> case. I'm trying to determine what the appropriate generic would be in >> lieu of my pseudo code. I've dug into the generated table classes, and >> I've found this (apologies for the naming inconsistencies, I have some >> refactoring to do): >> >> public class Galleries extends TableImpl<GalleriesRecord> { >> >> private static final long serialVersionUID = 1035239683; >> >> /** >> * The reference instance of <code>public.galleries</code> >> */ >> public static final Galleries GALLERIES = new Galleries(); >> >> /** >> * The class holding records for this type >> */ >> @Override >> public Class<GalleriesRecord> getRecordType() { >> return GalleriesRecord.class; >> } >> // .... >> >> However, I attempted to make the table object generic several different >> types shown here, but none worked. I think I'll try your polymorphic >> parameter suggestion here as well, as it seems to make more sense the more >> I type, but I'd like your input if you have a better idea. >> > > Aha, I see. You'd have to declare the generic type along the lines of this > (simplified): > > class BaseService<R extends Record, T extends Table<R>> { > T table(); > } > > Then, a GalleriesService could be defined as such: > > class GalleriesService extends BaseService<GalleriesRecord, Galleries> { > > } > > > Hope this helps getting you in the right direction > Lukas > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
