No, all foreign keys are required to have the suffix ‘_id’.

It’s hardcoded, and very complex to change (which is why it hasn’t happened yet).

But it might in 2.0!... Right?

It’s at the top of the todo list, yes.

Humm i´m new at Datamapper ORM, and im just reading all the documentation and trying some snnipets… But now this come to my mind…. If your are no longer mantaining HTML Form, how should i generate forms based on the models… i dont get it very well.

Thank you in advanced

Easy answer is: like you would make a form otherwise.

Having said that, there’s nothing wrong with the form extension, it works fine, check the included example application.

OK. Thank you for your answer….

Humm but the extension will work for any future release of DMO?

No guarantees, I only don’t make any promisses towards maintaining it.

I don’t write (new) CI applications anymore, and I haven’t used the extension in years. But the DM code is very stable, and as CI itself hardly changes, there isn’t much to maintain, and I don’t see it breaking any time soon. Unless CI 3 is going to “pull a kohana”, but I don’t think so…

Pull a Kohana hm? Lets hope not.

It’s a shame you don’t write new CI apps anymore, why not!

I myself am up to the point where I want to use related queries. It’s still a bit iffy in my head:

Imagine a object Person and a object Car. A Person can have a Car. A Car can have some Wheel objects. The thing is I want to related the Wheel objects specifically to the Person.

In example: Bob buys a Ford. The Ford has four objects of ‘Fancy Wheels’. That is Bob’s Ford, not everyone else’s.

Am I right to assume I have to relate that by get_by_related somehow? If so the pages on related stuff, I don’t seem to quite get. Can anyone enlighten the subject to me through this example?

The why has been discussed in the past.

You need to pick the right tools for the job, and CI just wasn’t (anymore). I was sick and tired bolting lots of stuff on, and extending most of the core classes, to make it into what I needed. Applications became fat, slow and bloated.

Having said that CI still is the right tool for a lot of jobs for a lot of people. Which is why I still maintain DM. It’s just not for me anymore.

As to your question: in this case “Wheels” is a property of the relation between Bob and His Ford. Assuming that you currently have a many-to-many between Person and Car, I would convert this to two one-to-many’s, which a separate model for the join table (CarOwner). You can then relate all kinds of stuff to the Carowner model.

I can’t say I follow.

Wheels do need to know whose Car it is they are attached to, but I don’t see how a CarOwner model would be any different then a Person. And a separate model for the join table?

Lets talk database:

person: ID, [stuff]
car: ID, [stuff]
wheel: ID, [stuff]
join_person_car: ID, person_id, car_id
join_car_wheel: ID, car_id, wheel_id, person_id?

That is what I had in mind so far, but unsure how to do that with datamapper.

No, that’s not what I meant.

You currently have: Person -> has_many -> (via join_person_car) <- has_many <- Car (a many-many between Car and Person).

If Wheel is something specific about the combination of a car and a person, from a normalisation point of view it should be related to the join table, and not to either Person or Car.

This means you have to make a model for the join table (let’s call that PersonCar), otherwise you can’t relate something to it.

You now get:
- Person -> has_many - <- has_one <- PersonCar
- Car -> has_many - <- has_one <- PersonCar

This will still be a many to many between Person and Car. If you define a custom tablename of ‘join_person_car’ for the PersonCar model, you don’t even have to change the many to many for direct access via Person or Car.

Now that you have this, you can relate other models of PersonCar:
- PersonCar -> has_one -> Wheel (which has wheel_id in PersonCar)

WanWizard - 04 November 2012 06:58 PM

No guarantees, I only don’t make any promisses towards maintaining it.

I don’t write (new) CI applications anymore, and I haven’t used the extension in years. But the DM code is very stable, and as CI itself hardly changes, there isn’t much to maintain, and I don’t see it breaking any time soon. Unless CI 3 is going to “pull a kohana”, but I don’t think so…

:( But i´m not very clear… you will keep DM ORM mantained?

Abot what you said… you dont prefer CI anymore, what do you recommend us then?

Yes, I will.

I can’t recommend anything. You choose the right tool for the job. For me, that wasn’t CI anymore.

Hello, I’m using the login example listed on the datamapper website. What I’m trying to build now is a function to allow users to change their password. I want the user to input their current password before allowing a new password to be saved. Simply saving a new password for the user works fine:

how would I go about doing this:

obviously the above will not work because it’s comparing a plaintext password against something already encrypted… thoughts?

Encrypt it before comparing it. I can’t recall the encryption the example uses, but something like this: