Re: Re(3): Mixing Mysql and Perl

[exussum0]

Yes, I took a look at it.

Your object attributes don't always coincide with your table columns. It's not always 1-1. And the pixie model may be great and all, but if you hook it up to a db, then you must care what it does for performance sake. A missing index could cause a world of trouble if pixie decided to pull back an object using the wrong method (verb, not object).

If piexie doesn't care about how your db is laid out, then see above, it may not be using indicies correctly, or not doing thins in an efficient manner, ala selecting large groups of data (multiple rows etc..).

If you haven't used pixie yourself, I'm not quite sure how you can be so confident in it, regardless of who wrote it, since the best programmers in the world can still make the strangest mistakes. You prolly won't believe me anyway, here is a document from IBM on pixie and it's drawbacks as well as its pluses.

As you see, for small projects, it prolly does wonders, but for a huge project, I doubt I would look at it all that quickly, since custom SQL is usually better than that generated by a general api.

-s

[Ovid]

sporty, you talk about objects not coinciding with tables. You mention that object attributes do not always match your table columns. You're raising some very valid concerns about object-relational mappers. Pixie is not an object-relational mapper. I never said it was an object-relational mapper. Pixie does not claim to be an object-relational mapper. Objects do not map to tables and attributes do not map to columns (in fact, the IBM article you linked to made that very clear). I don't know what you were talking about, but you certainly weren't talking about Pixie. It's for persisting objects, that's all. If someone wants to use it as an object-relational mapper, they're going to be disappointed.

You wrote: If you haven't used pixie yourself, I'm not quite sure how you can be so confident in it ....

I did not say that I'm confident in it. I wrote "I've not used it, but it sounds very interesting." I wasn't making specious claims. I simply said it was interesting.

I'm not entirely sure of what you're criticizing here, but you're criticisms are irrelevant to Pixie in the same way that if someone says they can't stand the sound of purring, that criticism would be irrelevant to dogs.

You also wrote:

As you see, for small projects, it prolly does wonders, but for a huge project, I doubt I would look at it all that quickly, since custom SQL is usually better than that generated by a general api.

I agree with you on that, but Pixie is for object persistence. If I were to use my objects as bundles of data with behaviors attached to them, Pixie is probably a bad choice. If I reverse that and look at objects as behaviors that have data associated with them, Pixie might make more sense. If I have to write huge blocks of custom SQL, then I am taking a data-centric approach (which is perfectly fine), and I wouldn't use Pixie. I did not claim that Pixie is the perfect solution to any problem. I merely mentioned it as a possible approach and certainly didn't claim it was the solution the original poster should adopt. Again, I merely said it was "interesting".

Update: I'm not responding to your last post because I just want this thread to end. Yes, the original poster was asking about mapping SQL to Perl. I'm quite aware of that. However, I mentioned Pixie almost as an afterthought on the off chance that it might prove beneficial and you decided to comment about that. I find it disappointing you spent so much time arguing about Pixie when you clearly had no idea what it was. In your final response, you completely didn't respond to anything I said and instead you took the trouble to raise an irrelevant issue. I'm done with this.