On Feb 15, 2010, at 1:56 PM, Marius wrote:
> The author says something like "The moment you define a domain
> abstraction as being statically dependent on a persistence
> implementation, you lose the ability to reuse it in other contexts.".
> I disagree completly. I can think of a couple of options
I hardly "own" the Record :) ... as I stated with other occasions I'm
not a fan of ORM either :) ( I'm also not a fan of annotated POJO crap
which claim purity but they are polluted with annotations. )
I didn't follow too closely the couch DB implementation so I don't
have a formed opinion on it.
On Thu, Aug 27, 2009 at 11:48 AM, inca wrote:
>
> Ok, thanks. Another question then. As far as I can see from sources,
> basic KeyedRecord trait depends on some Mapper classes. Does Record
> use Mapper for JDBC operations under the covers?
Yes.
>
>
> On 27 авг, 01:25, Timothy Perrett wrote:
>
Ok, thanks. Another question then. As far as I can see from sources,
basic KeyedRecord trait depends on some Mapper classes. Does Record
use Mapper for JDBC operations under the covers?
On 27 авг, 01:25, Timothy Perrett wrote:
> Its not the primary ORM at the moment. Although, its developing, an
Its not the primary ORM at the moment. Although, its developing, and its
still simply awesome if you are not using JDBC storage.
If you just need regular JDBC style connectivity, then use Mapper for now.
Cheers, Tim
On 26/08/2009 19:01, "inca" wrote:
> Is there any documentation available fo
On Wed, Nov 26, 2008 at 10:36 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> IMO, there is a wider issue here at large:
>
> Should we be providing a way / central repo for lift plugins (read:
> modules) that are part of lift proper? Kind of like a lift-extras
> repo? Possibly host it on scala-tool
IMO, there is a wider issue here at large:
Should we be providing a way / central repo for lift plugins (read:
modules) that are part of lift proper? Kind of like a lift-extras
repo? Possibly host it on scala-tools?
Cheers
Tim
On 26 Nov 2008, at 18:32, David Pollak wrote:
> We will not be
On Wed, Nov 26, 2008 at 10:28 AM, Marius <[EMAIL PROTECTED]> wrote:
>
> I believe so. Record/Field currently provide necessary abstraction and
> server side validation structure. JDBC implementation for Record stuff
> it's on its way ... and of course one could write a DB4O
> implementation for it
I believe so. Record/Field currently provide necessary abstraction and
server side validation structure. JDBC implementation for Record stuff
it's on its way ... and of course one could write a DB4O
implementation for it.
I think it would be sweet to have such integration in the future but I
don'
On Nov 16, 2:29 am, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
> That's funny, I just checked out the wip-record2-dpp branch this morning to
> start looking at it :) So far, I really like what I see. I would agree with
> Tim on calling it Persistable... vs DB... but otherwise it's looking ve
On Nov 16, 1:32 am, Tim Perrett <[EMAIL PROTECTED]> wrote:
> wow this is super sweet marius!
>
> A couple of questions:
>
> - net.liftweb.record.Test... shouldn't this be in the tests package?
I'll remove this. My bad.
> - DBRecord, whats the difference between this and ordinary record?
DBReco
That's funny, I just checked out the wip-record2-dpp branch this morning to
start looking at it :) So far, I really like what I see. I would agree with
Tim on calling it Persistable... vs DB... but otherwise it's looking very
good. If I have some time this week I might start looking at how to meld
wow this is super sweet marius!
A couple of questions:
- net.liftweb.record.Test... shouldn't this be in the tests package?
- DBRecord, whats the difference between this and ordinary record?
Looking at the code, it appears that DBRecord just adds some abstract
stuff like stubbs for save methods
13 matches
Mail list logo
