overriding lazy value id in trait *ProtoUser* of type net.liftweb.record.field.LongField[domain.model.User]; [error] *method id in trait KeyedRecord of type => Long needs `override' modifier*
On Mon, Oct 1, 2012 at 6:47 AM, Etam <odwrot...@gmail.com> wrote:
> Hi,
> how dou you use ProtoUser with Squeryl records?
> There is a problem:
> overriding lazy value id in trait *ProtoUser* of type
> net.liftweb.record.field.LongField[domain.model.User];
> [error] *method id in trait KeyedRecord of type => Long needs `override'
> modifier*
[error] /etabl/src/main/scala/com/etabl/model/User.scala:14: overriding type FieldPointerType in trait MetaMegaProtoUser, which equals net.liftweb.mapper.MappedField[_, com.etabl.model.User.TheUserType]; [error] type FieldPointerType in trait CRUDify, which equals net.liftweb.mapper.MappedField[_, com.etabl.model.User] needs `override' modifier; [error] other members with override errors are: computeFieldFromPointer, buildFieldBridge, editPath, menus
while:
object User extends User with MetaMegaProtoUser[User] with CRUDify[Long, User] { ...
I had to change its name. This is a very dirty solution ;).
I agree that it's dirty, but I don't see why you'd have issues with
override. If you copy the code into your own project, you should be able
to just change the methods directly.
On Mon, Oct 1, 2012 at 3:35 PM, Etam <odwrot...@gmail.com> wrote:
> Hmmm :(, there is another problem:
> [error] /etabl/src/main/scala/com/**etabl/model/User.scala:14: overriding
> type FieldPointerType in trait MetaMegaProtoUser, which equals
> net.liftweb.mapper.**MappedField[_, com.etabl.model.User.**TheUserType];
> [error] type FieldPointerType in trait CRUDify, which equals
> net.liftweb.mapper.**MappedField[_, com.etabl.model.User] needs
> `override' modifier;
> [error] other members with override errors are: computeFieldFromPointer,
> buildFieldBridge, editPath, menus
> while:
> object User
> extends User
> with MetaMegaProtoUser[User]
> with CRUDify[Long, User] { ...
> I had to change its name. This is a very dirty solution ;).
> I agree that it's dirty, but I don't see why you'd have issues with > override. If you copy the code into your own project, you should be able > to just change the methods directly.
On Wed, Nov 14, 2012 at 1:02 PM, Etam <odwrot...@gmail.com> wrote:
> Is it going to be fixed?
> W dniu poniedziałek, 1 października 2012 22:13:57 UTC+2 użytkownik David
> Whittaker napisał:
>> I agree that it's dirty, but I don't see why you'd have issues with
>> override. If you copy the code into your own project, you should be able
>> to just change the methods directly.
I had considered refactoring ProtoUser so that it doesn't define an id
field. Squeryl 0.9.6 will be more flexible about how primary keys are
defined though. Right now, I'm leaning towards waiting until it's
released, then adding ProtoUser support to the SquerylRecord version based
on it.
On Thu, Nov 15, 2012 at 4:24 AM, Etam <odwrot...@gmail.com> wrote:
> The ProtoUser class so you could be able to extend it with KeyedRecord
> from SquerylRecord.
> W dniu środa, 14 listopada 2012 20:45:07 UTC+1 użytkownik David Whittaker
> napisał: